microsoft/win-dev-skills: Copilot agents for the WinUI 3 inner loop

The gap between a WinUI 3 scaffold and a shipped app

Setting up a WinUI 3 project by hand means assembling a chain of tools that each fail in their own way: the .NET SDK, the Windows App SDK, the WinApp CLI, templates, and Developer Mode. The README describes the plugin as covering the end-to-end inner loop, scaffold, design, build, run, test, package, ship, which is a claim about breadth rather than about any single step being hard. The audience is developers who already work inside an agent session and want the Windows-specific parts of that session to be grounded in something more specific than a general-purpose coding assistant. If you are not using Copilot CLI, Claude Code, Codex, OpenClaw or OpenCode, this package has nothing to offer you, because it installs into those hosts and nowhere else.

How the plugin is structured on disk

The repository is a plugin marketplace. Adding it as a marketplace and installing winui@win-dev-skills is the two-command shape across hosts. Underneath, the material shows a plugins/winui directory containing an agent-plugin folder with a skills subdirectory, and each skill is a folder with a SKILL.md file. That layout matters because OpenCode is documented as loading Agent Skills natively from <name>/SKILL.md folders, so the same files serve as plugin content for Copilot and as plain skill directories for OpenCode. The README also refers to a marketplace manifest that OpenClaw reads when installing from --marketplace. The README states the package contains eight skills, and OpenClaw verification is done with openclaw skills list, where each entry should show a ready marker. Skill invocation is by name, with /winui-setup and /winui-design given as examples.

Agents versus skills, and why the host matters

The package ships both an orchestrator agent named winui-dev and a set of skills, but not every host exposes both. The README is explicit that Codex has no agents concept, so the orchestrator is not exposed there; the same note appears for OpenClaw and OpenCode. In those three hosts the skills still load on demand when invoked by name. That is a real functional difference, not a cosmetic one: on Copilot CLI you can activate winui-dev and let it route work, while elsewhere you decide which skill to call. If your workflow depends on an agent deciding when to run a design pass versus a packaging pass, the plugin behaves differently depending on which CLI you installed it into. The README does not describe how the orchestrator chooses among skills, so that routing behaviour is not something you can evaluate from the documentation alone.

Installing the plugin and its prerequisites

For Copilot CLI the README gives copilot plugin marketplace add microsoft/win-dev-skills followed by copilot plugin install winui@win-dev-skills, or a one-liner from the awesome-copilot listing: copilot plugin install winui@awesome-copilot. Claude Code uses claude plugin marketplace add microsoft/win-dev-skills then claude plugin install winui@win-dev-skills. OpenClaw takes openclaw plugins install winui --marketplace microsoft/win-dev-skills followed by openclaw gateway restart, or installs from a local clone path ./win-dev-skills/plugins/winui. OpenCode is the odd one out: it is pointed at the shared skills directory with a PowerShell snippet that creates directory junctions from plugins/winui/agent-plugin/skills into $env:USERPROFILE\.config\opencode\skills. Because those are junctions rather than copies, a git pull in the repo picks up upstream skill changes without re-linking. Prerequisites are listed as Git 2.54, .NET SDK 8.0.100 minimum with 10.0 recommended, WinApp CLI 0.6.0 minimum, and Developer Mode enabled via the DWORD AllowDevelopmentWithoutDevLicense set to 1. Visual Studio is not required; the skills build and run with dotnet, and the README notes neither setup path installs it. The README also states that WinApp CLI 0.6 and later installs and updates WinUI templates on demand through winapp new, so templates should not be installed separately.

The XAML compiler failure this package is built around

The most concrete technical detail in the README is a Windows App SDK bug. Under dotnet build, a malformed .xaml file used to produce no useful diagnostic: the build failed with MSB3073, reported as XamlCompiler.exe exiting with code 1, and gave no indication of which .xaml file was wrong. The README states this is fixed in current releases, specifically Windows App SDK 2.1.3 or later on the 2.x line and 1.8 or later on the 1.x line. The practical consequence is a version floor that has nothing to do with the plugin's own code. If your project is pinned to an older Windows App SDK, a skill-driven build loop will hand you a cryptic MSB3073 and no file name, and no amount of agent assistance changes that, because the missing information never reaches the build log. The README's text on this point is truncated mid-sentence in the supplied material, so the full remediation guidance is not available here.

Preview status, pinning, and what breaks

The README carries a warning box stating the project is preview v0.x and that skill names, on-disk layout, agent configuration, analyzer rule IDs and CLI tool surfaces are all subject to change without notice. It states there is no SemVer commitment until v1.0 and recommends installing from a release tag rather than the rolling marketplace if you need a stable pin. The repository metadata shows no releases retrieved, so the pinning advice currently has nothing to point at, which is worth checking before you build a workflow on it. The same warning box says outputs are suggestions, not authoritative answers, and should be reviewed before committing or shipping. That is the honest framing, and it also sets the ceiling: this is a scaffolding and prompting layer, not a compiler or a linter. Note that the MIT licence covers the repository contents; it does not extend to the Windows App SDK, the WinApp CLI, or the agent hosts you install into, each of which carries its own terms. Nothing here is legal advice.

Where a template or a plain SDK install is the better choice

The comparison that matters is against the WinUI 3 project templates themselves, which WinApp CLI 0.6 and later installs and updates on demand through winapp new. If your task is to create one project and start writing XAML, winapp new plus dotnet build is fewer moving parts than a plugin marketplace, an agent activation step and a skill invocation. The plugin adds value when the work is iterative and spans stages, because that is where an agent that knows the Windows App SDK conventions saves you from restating them each session. It also adds a dependency on whichever CLI you installed it into, and on the plugin's own layout being stable, which the README says it is not yet. For a one-off app, or for a team that does not use any of the five supported hosts, the templates and the SDK are the shorter path.

Maintenance cost and the upgrade path

There are two upgrade surfaces. The first is the plugin itself: on Copilot CLI, Claude Code and OpenClaw it comes through a marketplace, so updates arrive with the marketplace unless you pinned a release tag, and the README warns that pinned tags are the only way to avoid breaking changes before v1.0. On OpenCode the update mechanism is different and cheaper, since the junction links mean git pull refreshes the skills in place. The second surface is the toolchain the skills drive: .NET SDK, WinApp CLI and the Windows App SDK. The README's minimum versions are 8.0.100, 0.6.0 and, for the XAML compiler fix, 2.1.3 or 1.8 depending on the SDK line. Because the plugin's own release history is not visible in the supplied material, there is no way to judge how often skill names or analyzer rule IDs have actually churned. Treat the v0.x warning as the operating assumption and check the repository before pinning anything in a shared team setup.

Editorial conclusion

Adopt it if your team already drives WinUI 3 work from Copilot CLI, Claude Code or Codex and you want the scaffold, design, build, run, test and package steps handled by named skills rather than ad hoc prompting; install from a release tag rather than the rolling marketplace, since the README states there is no SemVer commitment until v1.0. Do not adopt it if you need a stable skill surface, a pinned analyzer rule set, or an orchestrator agent on Codex, OpenClaw or OpenCode, where the README notes the winui-dev agent is not exposed. Verify first that dotnet --list-sdks reports 8.0.100 or newer, that winapp --version reports 0.6.0 or newer, and that the Developer Mode DWORD AllowDevelopmentWithoutDevLicense is set to 1.

Official sources

1. Issues
2. License: MIT
3. microsoft/win-dev-skills on GitHub
4. README