
Winui Code Review
Review WinUI 3 / XAML apps against Microsoft performance, security, accessibility, globalization, and code-quality rules before merge or release.
Overview
Winui-code-review is an agent skill most often used in Ship (also Build frontend) that audits WinUI XAML and related code against Microsoft performance, security, accessibility, globalization, and quality rules.
Install
npx skills add https://github.com/microsoft/win-dev-skills --skill winui-code-reviewWhat is this skill?
- Consolidated rules for performance, security, accessibility, globalization, and general code quality
- Performance guidance: prefer x:Bind over {Binding}, deferred x:Load, and x:Phase incremental list rendering
- Side-by-side x:Bind vs {Binding} comparison (compile-time vs reflection)
- Explicit reserve-{Binding} guidance for Style setters where x:Bind cannot apply
- DataTemplate examples with x:DataType and phased rendering patterns
- Consolidated rule sets across performance, security, accessibility, globalization, and code quality
- Documented x:Bind vs {Binding} comparison table with resolution, type safety, default mode, and performance
Adoption & trust: 24 installs on skills.sh; 269 GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
Your WinUI app works in dev but you lack a consistent checklist for bindings, deferred UI, list performance, a11y, and i18n before you ship.
Who is it for?
Indie developers building WinUI 3 desktop or packaged Windows apps who want Microsoft-specific review criteria in the agent loop.
Skip if: Teams only shipping web or mobile non-WinUI stacks, or repos with no XAML/WinUI surface to inspect.
When should I use this skill?
Reviewing or polishing WinUI XAML, bindings, list templates, or pre-release Windows client UI quality.
What do I get? / Deliverables
You get agent-guided review aligned to x:Bind, x:Load, x:Phase, and consolidated quality rules so you can fix issues before merge or store submission.
- Review feedback mapped to performance, security, accessibility, globalization, and code-quality rules
- Concrete XAML binding and rendering fixes (x:Bind, x:Load, x:Phase)
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Ship is the canonical shelf because the skill is a structured quality gate on finished UI code, even though teams can run it incrementally during build. Review subphase matches checklist-driven audits (x:Bind, x:Load, a11y, i18n) rather than writing new features.
Where it fits
Refactor a Settings flyout to use x:Load so the subtree is not instantiated until the user opens settings.
Run a pre-merge pass to catch {Binding} in templates where x:Bind is required for compile-time safety.
Tune a long virtualized list by applying x:Phase so titles render before thumbnails and descriptions.
How it compares
Use alongside generic code-review skills when you need WinUI binding and rendering specifics, not only language-level lint.
Common Questions / FAQ
Who is winui-code-review for?
Solo and small-team builders using Claude Code, Cursor, or similar agents on C# WinUI 3 / XAML codebases who want structured Microsoft quality rules during review.
When should I use winui-code-review?
During Ship review before a release or PR; during Build frontend when tuning DataTemplates and bindings; during Ship perf passes on scrolling lists and deferred dialogs.
Is winui-code-review safe to install?
It is reference and review guidance—confirm scope in your agent settings; review the Security Audits panel on this Prism page before trusting third-party skill packs in CI.
SKILL.md
READMESKILL.md - Winui Code Review
# Quality Rules — Detailed Reference Consolidated detailed rules from performance, security, accessibility, globalization, and code quality. --- ## Performance ### x:Bind vs {Binding} Always prefer `x:Bind` (compiled bindings) over `{Binding}` (runtime reflection). `x:Bind` resolves at compile time, generates strongly typed code, and avoids the reflection overhead of `{Binding}`. | Feature | `x:Bind` | `{Binding}` | |---|---|---| | Resolution | Compile-time | Runtime (reflection) | | Type safety | ✅ Yes | ❌ No | | Default mode | OneTime | OneWay | | Performance | Faster | Slower | Reserve `{Binding}` only where `x:Bind` cannot be used (e.g., `Style` setters). ### Deferred Loading with x:Load Use `x:Load` to defer creation of UI subtrees that aren't immediately visible (e.g., dialogs, secondary tabs, collapsed panels). The element is created only when `x:Load` evaluates to `true`. ```xml <StackPanel x:Name="SettingsPanel" x:Load="{x:Bind ViewModel.IsSettingsOpen, Mode=OneWay}"> <TextBlock Text="Settings content here" /> </StackPanel> ``` ### Incremental Rendering with x:Phase Use `x:Phase` inside `DataTemplate` to prioritize which parts of each list item render first. Phase 0 (default) renders immediately; higher phases render in subsequent passes. ```xml <DataTemplate x:DataType="vm:ItemViewModel"> <StackPanel> <TextBlock Text="{x:Bind Title}" /> <TextBlock Text="{x:Bind Description}" x:Phase="1" /> <Image Source="{x:Bind ThumbnailUrl}" x:Phase="2" /> </StackPanel> </DataTemplate> ``` ### Collection Virtualization Use `ListView`, `GridView`, or `ItemsRepeater` for any list that may exceed ~20 items. These controls create UI elements only for visible items and recycle them on scroll. ```xml <ScrollViewer> <ItemsRepeater ItemsSource="{x:Bind ViewModel.Items}"> <ItemsRepeater.Layout> <StackLayout Spacing="4" /> </ItemsRepeater.Layout> </ItemsRepeater> </ScrollViewer> ``` For large datasets, implement `ISupportIncrementalLoading` so the `ListView` fetches pages of data as the user scrolls. ### DispatcherQueue for UI-Thread Management ```csharp public async Task LoadDataAsync() { var data = await Task.Run(() => _service.GetExpensiveData()); DispatcherQueue.TryEnqueue(() => { ViewModel.Items.Clear(); foreach (var item in data) ViewModel.Items.Add(item); }); } ``` **Do not flood the queue.** Batch updates into a single `TryEnqueue` call rather than enqueuing per item. ### Async Patterns - Use `async/await` for I/O-bound work (file access, HTTP calls, database queries). - Use `Task.Run` for CPU-bound work (parsing, compression, image processing). - Never block the UI thread with `.Result`, `.Wait()`, or `.GetAwaiter().GetResult()`. ### Layout and Visual Tree - Minimize XAML visual tree depth — deep nesting compounds layout-pass cost. - Prefer `Grid` over nested `StackPanel` layouts when you need rows and columns. - Cache expensive computations and HTTP responses when appropriate. --- ## Security ### Secrets Management with PasswordVault Use the Windows Credential Locker (`PasswordVault`) to store secrets. Credentials are encrypted per-user, per-app. ```csharp using Windows.Security.Credentials; var vault = new PasswordVault(); vault.Add(new PasswordCredential("MyApp", username, accessToken)); var credential = vault.Retrieve("MyApp", username); credential.RetrievePassword(); string token = credential.Password; vault.Remove(credential); ``` ### DPAPI Encryption for Data at Rest For encrypting arbitrary data at rest (e.g., local cache files), use `DataProtectionProvider`: ```csharp using Windows.Security.Cryptography.DataProtection; using Windows.Storage.Streams; // Encrypt var provider = new DataProtectionProvider("LOCAL=user"); IBuffer encrypted = await provider.ProtectAsync(dataBuffer); // Decrypt var unprotectProvider = new DataProtectionProvider(); IBuffer decrypted = await unprote