agentleFS
Sign inStart free
MicrosoftKnown publishermicrosoft/winappCli/plugins/winui/agent-plugin/skills/winui-dev-workflow/SKILL.md

winui-dev-workflow

Skill1.4k starsChanged 55 days agoMITView on GitHub

Create, build, run, and fix build errors in WinUI 3 apps (C# or C++) with WinApp CLI 0.7+: winapp new, winapp run, Native AOT, crash diagnosis. Use for a new WinUI app or a WinUI project that fails to build or crashes. Not for WPF, WinForms, or Electron apps that only reference the Windows App SDK.

1 other project uses a version of this, 1 of them edited.

Adopted by

Steady: 0 new projects took it in the last 4 weeks, none the 4 weeks before.thin data

Week of Sep 13: 0 new projectsWeek of Sep 20: 0 new projectsWeek of Sep 27: 0 new projectsWeek of Oct 4: 0 new projectsWeek of Oct 11: 0 new projectsWeek of Oct 18: 0 new projectsWeek of Oct 25: 0 new projectsWeek of Nov 1: 0 new projects
Sep 2026Oct 2026Nov 2026
New projects taking a version of this file each week, over the 8 weeks our latest run read: only 0 in all, so this is a hint, not a trend.

Most recently taken up by

Who's talking about microsoft/winappCli

The biggest 5 of 52 mentions linking to the repository that our crawl found. Each line is their own headline.

See all 52

Talked about on GitHub, Bluesky and Stack Overflow (52 times).

On GitHub · 50

45 more on GitHub

On Bluesky · 1

On Stack Overflow · 1

The file

We split this skill into the rules it gives an agent

6 rules. About 0 are common, 2 are distinctive, and 4 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈2

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 4

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Run winapp new --list to discover the currently installed template short names.

    line 17
  2. Distinctive:

    Add the latest stable analyzer to each app project.

    line 26
  3. Distinctive:

    If build fails: Read all errors, batch-fix them in one pass, then rerun the same command.

    line 44
  4. Very specific:

    Keep packaged as the default and use project-mode winapp run for activation.

    line 91
  5. Very specific:

    Only for an explicitly requested unpackaged/debug experiment, set WindowsPackageType=None.

    line 92
  6. Very specific:

    Do not delete Package.appxmanifest.

    line 93

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Scope: WinUI 3 apps only. The Windows App SDK is not WinUI. A WPF, WinForms, Electron, or other app that references the Windows App SDK (for notifications, packaging, or other APIs) is not a WinUI app; keep its framework and don't apply this skill unless the task is to port it to WinUI 3. A WinUI 3 project has <UseWinUI>true</UseWinUI> or uses Microsoft.UI.Xaml.

Requires WinApp CLI 0.7+.

Create or Open a Project

New app — let WinApp CLI install/update the official templates and scaffold:

winapp new --name <AppName> --template winui-mvvm --template-version latest --use-defaults
cd <AppName>

Run winapp new --list to discover the currently installed template short names. Do not install the template pack separately and do not create the output directory first.

Existing app — read the .csproj to understand:

  • <TargetFramework> (e.g., net10.0-windows10.0.26100.0)
  • <PackageReference> versions (WindowsAppSDK, CommunityToolkit)
  • Project structure and established patterns

Add or Check the Per-App Analyzer

Add the latest stable analyzer to each app project; do not assume a template includes it:

dotnet add .\MyApp.csproj package Microsoft.Windows.SDK.BuildTools.WinUIAnalyzer

Keep PrivateAssets="all" on the reference. It loads in normal CLI, IDE, and CI builds; WinApp CLI does not inject it. If the package is unavailable, continue and tell the user its checks for potential runtime issues did not run. Undo only an incomplete reference added by this attempt; do not remove existing references or hide other restore failures.

For other packages, prefer the latest stable unless the project has a version policy or the user requests a specific version. Before coding API assumptions, use winapp find-api scoped to the restored app with --project-dir <app-project-dir> (or --project <name> in a solution); see winui-design.

Build & Run (JIT Development)

winapp run . --detach --json

For UI testing, see winui-ui-testing, which chooses the execution target itself.

Ordinary winapp run uses the build/JIT path, even with -c Release; it does not validate Native AOT. Use an explicit .csproj when project selection is ambiguous; see winapp run --help for options.

If build fails: Read all errors, batch-fix them in one pass, then rerun the same command.

Native AOT Publish Runs

For intended AOT deployment, set <PublishAot>true</PublishAot> in the app project (it also enables analysis during development); for a one-off trial, pass -p PublishAot=true. --aot publishes rather than builds; choose an --arch runnable on this machine:

winapp run . --aot -c Release --arch <x64|arm64> --detach --json
winapp run . --aot -c Release --arch <x64|arm64> -p PublishAot=true --detach --json

Fix IL/CsWinRT warnings rather than suppressing them. See winui-packaging's references/sourcegen-patterns.md.

Diagnosing Crashes

Run attached with --debug-output and invoke it with mode: "async", then read the same shell. On a WinUI crash, stowed-exception triage surfaces the real XAML error behind an opaque 0x8000FFFF / E_FAIL; add --symbols for richer native frames. The first crash downloads debugger components; set WINAPP_DBGTOOLS_DIR to an existing Debugging Tools for Windows install when offline. --debug-output cannot combine with --json or --no-launch.

Common Errors

ErrorFix
Developer Mode not enabledSettings → System → For developers → On
CS0234/CS0246 missing typeAdd using or dotnet add package
NETSDK1136 platform requiredTarget a Windows TFM (for example net10.0-windows10.0.26100.0); use -f <windows-tfm> when the project already multi-targets
XLS0414 XAML type not foundAdd xmlns declaration
XDG0062 binding path missingCheck x:Bind property exists on ViewModel
Dynamic bound value does not updateCheck effective mode, including inherited x:DefaultBindMode; use OneWay/TwoWay and change notifications where needed
App silently exitsUse project-mode winapp run; don't bypass packaged activation by running the .exe directly
App crashes with opaque 0x8000FFFF / E_FAILSee Diagnosing Crashes
XAML compiler crashes silentlyRemove any PresentationCore.dll / System.Windows references
MSB3073 / XamlCompiler.exe ... exited with code 1, no .xaml namedOld WindowsAppSDK XAML-compiler bug — update Microsoft.WindowsAppSDK NuGet to latest (≥ 2.1.3, or ≥ 1.8 on the 1.x line)
0x80073CF6 package install failedCheck the manifest publisher and Developer Mode; apps from winapp new need no separate winapp init
0x80073CF9 / "Failed to reach state Staged" on a deeply nested projectFor a packaged app, rerun with --output-appx-directory "$env:LOCALAPPDATA\winapp-layout\<app>-<config>-<arch>", or move the repo closer to the drive root. Keep the directory unique per configuration and architecture — a registered development package holds a live reference to it, so Debug and Release must not share one — and empty it before reuse so payload files dropped since the last build do not linger
0x8007000B bad image formatWrong platform target — use x64 or ARM64, not AnyCPU

Prerequisites

RequirementRequired for this workflow
WindowsWindows 10 v1903+ and the app's OS requirements
Developer ModeEnabled for development deployment
.NET SDK8.0.100 minimum plus the SDK required by the app's TFM (e.g., .NET 10 for net10.0-windows…)
WinApp CLI0.7+
Native AOT onlyMSVC C++ build tools (Visual Studio or Build Tools, Desktop development with C++ workload, target-architecture tools); not needed for normal builds

If WinApp CLI is missing or older than 0.7, install or upgrade it using winui-setup without asking (it needs no admin rights) and tell the user. Ask before installing anything that needs admin rights — the .NET SDK, Developer Mode, or the Native AOT toolchain; do not work around them.

Critical Rules

  • Keep packaged as the default and use project-mode winapp run for activation.
  • Only for an explicitly requested unpackaged/debug experiment, set WindowsPackageType=None; package-identity-dependent APIs may fail and runtime requirements still apply. Do not use this as a silent launch workaround. Preserve the manifest and restore the original packaged setting after the experiment.
  • Do not delete Package.appxmanifest.
  • ❌ NEVER use AnyCPU — always x64 or ARM64

References

  • winui-packaging — release packaging directly from the project; no development registration required.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free