winui-app
Bootstrap, develop, and design modern WinUI 3 desktop applications with C# and the Windows App SDK using official Microsoft guidance, WinUI Gallery patterns, Windows App SDK samples, and CommunityToolkit components. Use when creating a brand new app, preparing a machine for WinUI, reviewing, refactoring, planning, troubleshooting, environment-checking, or setting up WinUI 3 XAML, controls, navigation, windowing, theming, accessibility, responsiveness, performance, deployment, or related Windows
Security Assessment
About winui-app
winui-app helps bootstrap, develop, and design modern WinUI 3 desktop applications in C# on the Windows App SDK, grounded in official Microsoft guidance, WinUI Gallery patterns, Windows App SDK samples, and CommunityToolkit components. It solves the problem of getting a WinUI 3 project set up correctly and building idiomatic, verified Windows UX rather than ad hoc structures. Its required flow starts by classifying each task as environment/setup, new-app bootstrap, design, implementation, review, or troubleshooting, then routing to the appropriate bundled reference file.
For machine setup and new apps, it runs the bundled WinGet configuration from the skill directory with winget configure -f config.yaml --accept-configuration-agreements --disable-interactivity, intended to enable Developer Mode and install or update Visual Studio Community 2026 with the Managed Desktop, Universal, and Windows App SDK C# components. It verifies the template with dotnet new list winui and scaffolds via dotnet new winui -o <name>, documenting supported options (such as -f net10.0/net9.0/net8.0, -slnx, -cpm, -mvvm, -imt, -un/--unpackaged, -nsf, --force) and warning not to invent unsupported flags. It makes the packaging model (packaged vs unpackaged) explicit, guides recovery from opaque XAML compiler failures like MSB3073 by simplifying back to the template scaffold, and requires building and running the app to confirm a real top-level window before responding. Design rules favor native WinUI and Fluent patterns: prefer stock controls like CommandBar over custom rows, compose or restyle built-in controls before adding CommunityToolkit, support light and dark mode with theme-aware resources, plan responsive wide/medium/phone behavior, and avoid unnecessary Border wrappers or double-card compositions.
Target users are developers building or maintaining WinUI 3 apps who need grounded setup, modern UX decisions, or concrete implementation patterns. The skill ships numerous reference files (foundation setup, environment audit, controls and layout, navigation and windowing, theming, accessibility, performance, testing) plus config.yaml and an agents definition. It prefers Microsoft Learn for requirements, WinUI Gallery for control usage, and WindowsAppSDK-Samples for scenario APIs, and requires launch verification with objective success signals before considering work complete.
FAQ
How does the skill set up a machine for WinUI development?
It runs the bundled WinGet configuration from the skill directory: winget configure -f config.yaml --accept-configuration-agreements --disable-interactivity. This is intended to enable Developer Mode and install or update Visual Studio Community 2026 along with the Managed Desktop, Universal, and Windows App SDK C# components. For diagnostics-only requests it warns the changes could modify the machine and asks for confirmation first.
How is a new app scaffolded and which template options are supported?
After verifying the template with dotnet new list winui, it scaffolds with dotnet new winui -o <name>. Supported options include -f|--framework net10.0/net9.0/net8.0, -slnx, -cpm, -mvvm, -imt, -un|--unpackaged, -nsf, and --force. It does not invent unsupported flags and only uses --force if the user explicitly asks to overwrite.
What does the skill consider a successful launch?
Launch verification is incomplete until the app shows objective success signals such as a responsive top-level window, the expected window title, or other clear startup behavior. A spawned process by itself is not enough. For any work that creates or changes an app, it builds and runs before responding, and leaves the final verified instance running unless told otherwise.
What are the design defaults for building UI?
Prefer native WinUI and Fluent patterns: use stock command surfaces like CommandBar instead of custom button rows, compose or restyle built-in controls and system resources before adding CommunityToolkit or authoring custom controls, support both light and dark mode with theme-aware resources, avoid unnecessary Border wrappers and double-card compositions, and plan explicit wide, medium, and phone-width responsive behavior.
How should opaque XAML compiler failures be handled?
For opaque XAML compiler failures such as MSB3073 or XamlCompiler.exe errors, read references/foundation-template-first-recovery.md and simplify back toward the current dotnet new winui scaffold for the chosen packaging model before inventing custom recovery structure.
All Files
20 filesInstall winui-app
Quick Setup:
- Copy the skill folder to
.claude/skills/ - Claude will automatically detect and use the skill
Repository
openai/skills