Add OpenCode winui-dev orchestrator agent

CHANGELOG.md

@@ -23,6 +23,8 @@ The `version-bump` and `changelog-entry` CI jobs enforce this.
 
 ### Added
 
+- Added an OpenCode `winui-dev` orchestrator agent (`plugins/winui/opencode/agent/winui-dev.md`) that loads `winui-dev-workflow` and `winui-design` on demand, so OpenCode users can run `opencode run --agent winui-dev` for end-to-end WinUI 3 builds.
+
 ### Changed
 
 ### Fixed

README.md

@@ -91,6 +91,47 @@ Verify the eight skills loaded with `openclaw skills list` (each shows `✓ read
 > **Note:** OpenClaw maps skills, not agents, so the `winui-dev` orchestrator agent isn't exposed there. The skills still work - ask the agent for a WinUI task and it loads the relevant skill on demand.
 </details>
 
+<details>
+<summary><strong>OpenCode</strong></summary>
+
+OpenCode ships a `winui-dev` orchestrator agent that loads the shared skills and
+does the WinUI 3 build work end to end. Link the agent and the skills it depends
+on into OpenCode's global config directory (no fork or copy needed):
+
+```powershell
+# One-time setup: link the agent + shared skills into OpenCode's global config
+$src = "C:\path\to\win-dev-skills\plugins\winui"
+$dst = "$env:USERPROFILE\.config\opencode"
+New-Item -ItemType Directory -Force "$dst\agent", "$dst\skills" | Out-Null
+
+# Shared skills (loaded on demand by the agent)
+Get-ChildItem "$src\skills" -Directory | ForEach-Object {
+  $link = Join-Path "$dst\skills" $_.Name
+  if (-not (Test-Path $link)) {
+    New-Item -ItemType Junction -Path $link -Target $_.FullName | Out-Null
+  }
+}
+
+# Orchestrator agent
+$agent = "$dst\agent\winui-dev.md"
+if (-not (Test-Path $agent)) {
+  New-Item -ItemType Junction -Path $agent -Target "$src\opencode\agent\winui-dev.md" | Out-Null
+}
+```
+
+Because these are junctions (not copies), `git pull` in the repo picks up upstream
+updates automatically. Then start OpenCode with the orchestrator:
+
+```powershell
+opencode run --agent winui-dev
+```
+
+The `winui-dev` agent loads `winui-dev-workflow` (build & run) and `winui-design`
+(Fluent Design, control selection, and `winui-search.exe` for grounded lookup) on
+demand, so there's no need to invoke the skills manually. The individual skills can
+also be invoked by name (e.g. `/winui-setup`) as usual.
+</details>
+
 Then start a new session and run the `winui-setup` skill with `/winui-setup`.
 
 Once setup is done, try a real task:

plugins/winui/opencode/agent/winui-dev.md

@@ -0,0 +1,28 @@
+---
+description: "Builds WinUI 3 desktop applications using Windows App SDK, XAML, and C#. Use for creating new apps, adding features, converting from WPF/Electron/web, fixing bugs, or any WinUI 3 / WinAppSDK / XAML task."
+mode: all
+permission:
+  question: allow
+  plan_enter: allow
+---
+
+## You Are The WinUI Developer — Do The Work Yourself
+
+You are `winui-dev` — don't call `task` with `subagent_type: "winui-dev"` (self-hop). `task` is fine for scoped helpers (`explore` for parallel codebase mapping, `general` for rubber-duck critique), not for the build itself.
+
+## Process
+
+You build WinUI 3 desktop apps following this process: understand requirements → design and plan UI → scaffold if needed → write code → build & run. The user might ask you to use other steps defined by skills such as `winui-ui-testing` for UI validation or `winui-code-review` for quality checks if desired only.
+
+Before continuing
+
+1. Load the `winui-dev-workflow` skill with `/winui-dev-workflow` — it has `BuildAndRun.ps1` for building and running your app
+2. Load the `winui-design` skill with `/winui-design` — it has Fluent Design rules, control selection, XAML correctness, and theming guidance, **and it bundles `winui-search.exe` for grounded control lookup against the WinUI Gallery, Community Toolkit, and Reactor catalogue**
+
+## Best Practices
+
+- **Efficiency:** Batch file creates/edits in one pass. Don't re-read files you just wrote. Chain dependent commands with `&&`.
+- **ReadEfficiently:** Read files efficiently. Avoid reading the same file multiple times. Use caching or batch operations when possible.
+- **Principles:** YAGNI (no speculative abstractions), DRY (search before writing new code), KISS (simplest solution that works).
+- **Accessibility:** Set `AutomationProperties.AutomationId` on every interactive control (Button, TextBox, ComboBox, CheckBox, ToggleSwitch, NavigationViewItem). Use unique naming for each control.
+- **Code quality:** File-scoped namespaces, `_camelCase` private fields, PascalCase types/methods/properties, `Async` suffix on async methods, `Is/Has/Can` prefix on booleans.