Agent skill
dotnet-winui
Build or review WinUI 3 applications with the Windows App SDK, including MVVM patterns, packaging decisions, navigation, theming, windowing, and interop boundaries with other .NET stacks. Use when building modern Windows-native desktop UI.
Install this agent skill to your Project
npx add-skill https://github.com/managedcode/dotnet-skills/tree/main/catalog/Frameworks/WinUI/skills/dotnet-winui
SKILL.md
WinUI 3 and Windows App SDK
Trigger On
- building native modern Windows desktop UI on WinUI 3
- integrating Windows App SDK features into a .NET app
- deciding between WinUI, WPF, WinForms, and MAUI for Windows work
- implementing MVVM patterns in Windows App SDK applications
Workflow
- Confirm WinUI is the right choice — use when modern Windows-native UI, Fluent Design, and Windows App SDK capabilities are needed. For cross-platform, consider MAUI instead.
- Choose packaging model early — packaged (MSIX) vs unpackaged differ materially for deployment, identity, and API access:
xml
<!-- Unpackaged: add to .csproj --> <WindowsPackageType>None</WindowsPackageType> - Apply MVVM pattern with the MVVM Toolkit — keep views dumb, logic in ViewModels:
csharp
public partial class ProductsViewModel : ObservableObject { [ObservableProperty] private ObservableCollection<Product> _products = []; [ObservableProperty] [NotifyCanExecuteChangedFor(nameof(DeleteCommand))] private Product? _selectedProduct; [RelayCommand(CanExecute = nameof(CanDelete))] private async Task DeleteAsync() { if (SelectedProduct is null) return; await _productService.DeleteAsync(SelectedProduct.Id); Products.Remove(SelectedProduct); } private bool CanDelete() => SelectedProduct is not null; } - Use x:Bind for compiled bindings — better performance and compile-time checking than
{Binding}:xml<TextBlock Text="{x:Bind ViewModel.Title, Mode=OneWay}"/> - Wire DI through
Host.CreateDefaultBuilder— register services, ViewModels, and views. Resolve viaApp.GetService<T>(). - Implement navigation service — map ViewModels to Pages by convention. See references/patterns.md for the full pattern.
- Handle Windows App SDK features — windowing (AppWindow), custom title bar, app lifecycle, notifications.
- Always set
XamlRootwhen showing ContentDialog — omitting this causes silent failures. - Validate on Windows targets — behavior depends on runtime, packaging model, and Windows version.
flowchart LR
A["Choose WinUI"] --> B["Select packaging model"]
B --> C["MVVM + DI setup"]
C --> D["Navigation and views"]
D --> E["Windows App SDK features"]
E --> F["Validate on target runtime"]
Key Decisions
| Decision | Guidance |
|---|---|
| Packaged vs unpackaged | Packaged (MSIX) for Store, auto-update, and full API access; unpackaged for simpler deployment |
| x:Bind vs Binding | Always prefer x:Bind — compiled, faster, type-safe |
| MVVM Toolkit attributes | Use [ObservableProperty], [RelayCommand] to eliminate boilerplate |
| Navigation | Convention-based ViewModel→Page mapping via navigation service |
| Theming | Use RequestedTheme on root element; respect system theme by default |
Deliver
- modern Windows UI code with clear platform boundaries
- explicit deployment and packaging assumptions
- MVVM pattern with testable ViewModels
- cleaner interop between shared and Windows-specific layers
Validate
- WinUI is chosen for a real product reason, not defaulted to
- Windows App SDK dependencies are explicit in the project file
- packaging and runtime assumptions are tested on target
- x:Bind is used for compiled bindings throughout
- navigation and ContentDialog both work with correct XamlRoot
- custom title bar renders correctly on Windows 10 and 11
References
- references/patterns.md - WinUI 3 patterns including MVVM, navigation services, DI setup, windowing, theming, dialogs, and lifecycle handling
- references/anti-patterns.md - common WinUI mistakes with explanations and corrections
Recommended Agent Skills
Expand your agent's capabilities with these related and highly-rated skills.
dotnet-project-setup
Create or reorganize .NET solutions with clean project boundaries, repeatable SDK settings, and a maintainable baseline for libraries, apps, tests, CI, and local development.
csharp-scripts
Run single-file C# programs as scripts (file-based apps) for quick experimentation, prototyping, and concept testing. Use when the user wants to write and execute a small C# program without creating a full project.
dotnet-pinvoke
Correctly call native (C/C++) libraries from .NET using P/Invoke and LibraryImport. Covers function signatures, string marshalling, memory lifetime, SafeHandle, and cross-platform patterns. USE FOR: writing new P/Invoke or LibraryImport declarations, reviewing or debugging existing native interop code, wrapping a C or C++ library for use in .NET, diagnosing crashes, memory leaks, or corruption at the managed/native boundary. DO NOT USE FOR: COM interop, C++/CLI mixed-mode assemblies, or pure managed code with no native dependencies.
nuget-trusted-publishing
Set up NuGet trusted publishing (OIDC) on a GitHub Actions repo — replaces long-lived API keys with short-lived tokens. USE FOR: trusted publishing, NuGet OIDC, keyless NuGet publish, migrate from NuGet API key, NuGet/login, secure NuGet publishing. DO NOT USE FOR: publishing to private feeds or Azure Artifacts (OIDC is nuget.org only). INVOKES: shell (powershell or bash), edit, create, ask_user for guided repo setup.
dotnet-legacy-aspnet
Maintain classic ASP.NET applications on .NET Framework, including Web Forms, older MVC, and legacy hosting patterns, while planning realistic modernization boundaries.
dotnet-code-review
Review .NET changes for bugs, regressions, architectural drift, missing tests, incorrect async or disposal behavior, and platform-specific pitfalls before you approve or merge them.
Didn't find tool you were looking for?