xaml-csharp-development-skill-for-uno

name

xaml-csharp-development-skill-for-uno

description

Build, review, design, migrate, and optimize Uno Platform applications and Uno framework source-tree changes with modern WinUI 3 XAML/C# patterns, Uno.Sdk configuration, typed bindings, dependency properties, control templating, Skia or native rendering choices, design systems, and platform-specific C#/XAML. Use for tasks involving Uno app startup and solution structure, target-platform setup, view and viewmodel composition, x:Bind or binding work, themes and resources, custom controls, Hot Reload or Dev Server workflows, performance, troubleshooting, testing, work inside the `/Users/wieslawsoltes/GitHub/uno` repo, or Avalonia-to-Uno migration work.

XAML and C# Cross-Platform Development (for Uno)

Use this skill to produce WinUI-first, source-generator-friendly, cross-platform Uno apps that stay maintainable across desktop, mobile, browser, and Windows App SDK targets.

Assume the primary source repository is /Users/wieslawsoltes/GitHub/uno. If the repo is checked out elsewhere, resolve the same doc/articles and src/ paths relative to that root before proceeding.

Primary entry for the full reference set:

• references/compendium.md

Workflow

1. Define app scope, API surface, and solution model first.

• Read references/00-api-map.md.
• Read references/01-architecture-and-lifetimes.md.
• Read references/05-platforms-bootstrap-and-solution-shape.md.
• Choose target platforms, renderer strategy, and solution shape before editing views.

2. Lock Uno.Sdk, MSBuild, and build lanes before UI work.

• Read references/06-msbuild-uno-sdk-and-tooling.md.
• Read references/21-supported-features-libraries-and-upgrades.md.
• Decide UnoFeatures, target frameworks, package versions, and upgrade constraints up front.

3. Establish binding, XAML, markup, and generator strategy.

• Read references/02-bindings-xaml-markup-and-generators.md.
• Read references/03-threading-dispatching-and-reactive-flows.md.
• Read references/22-source-generators-xbind-and-internals.md.
• Prefer XAML-first guidance and use x:Bind for typed or hot-path bindings; use {Binding} when DataContext indirection is the right tradeoff.

4. Build navigation, views, and interaction routing.

• Read references/11-navigation-views-and-composition.md.
• Read references/15-input-focus-accessibility-and-automation.md.
• Keep navigation state, dialogs, and interaction policy explicit instead of scattering platform checks through the UI tree.

5. Author dependency properties, styles, themes, resources, and design systems as one system.

• Read references/04-styles-themes-resources-and-design-systems.md.
• Read references/10-controls-templates-and-dependency-properties.md.
• Read references/14-assets-file-management-and-localization.md.
• Start app-level resources early, merge XamlControlsResources deliberately, and keep theme resources predictable.

6. Implement reusable controls, shells, and surface-level UI.

• Read references/10-controls-templates-and-dependency-properties.md.
• Read references/13-app-surfaces-dialogs-and-windowing.md.
• Separate control contract, template parts, and renderer-specific behavior.

7. Implement layout, list-heavy screens, and virtualization-sensitive UI.

• Read references/16-items-layout-and-large-data.md.
• Read references/17-rendering-modes-skia-native-and-platform-specific-ui.md.
• Choose control and renderer combinations with measurement, virtualization, and accessibility costs in mind.

8. Add motion, composition, custom drawing, or native interop only where justified.

• Read references/12-animations-composition-and-custom-rendering.md.
• Read references/17-rendering-modes-skia-native-and-platform-specific-ui.md.
• Prefer built-in storyboards, visual states, and standard controls first; drop to composition, Skia, or native embedding when the default stack is insufficient.

9. Complete storage, accessibility, automation, and platform-specific edges.

• Read references/14-assets-file-management-and-localization.md.
• Read references/15-input-focus-accessibility-and-automation.md.
• Read references/19-platform-specific-csharp-and-xaml.md.
• Keep platform-specific logic at the edges through partial files or conditional XAML.

10. Verify with runtime tests, diagnostics, and performance passes.

• Read references/07-troubleshooting.md.
• Read references/08-performance-checklist.md.
• Read references/18-testing-diagnostics-and-devserver.md.
• Validate on at least one fast inner-loop target first, then re-check platform-specific behavior on the real heads.

11. Finalize with examples, support-surface checks, and fast source lookup.

• Read references/09-end-to-end-examples.md.
• Read references/21-supported-features-libraries-and-upgrades.md.
• Use references/api-index.md for namespaces, packages, source directories, and grep patterns.

12. For Avalonia-to-Uno migration work, use the dedicated migration lane.

• Read references/24-avalonia-to-uno-migration-guide.md.
• Cross-check references/02-bindings-xaml-markup-and-generators.md.
• Cross-check references/10-controls-templates-and-dependency-properties.md.
• Cross-check references/19-platform-specific-csharp-and-xaml.md.

13. For Uno framework source-tree work, use the dedicated contributor lane.

• Read references/25-uno-repo-contributor-lane.md.
• Cross-check references/18-testing-diagnostics-and-devserver.md.
• Cross-check references/22-source-generators-xbind-and-internals.md.
• Respect the repo-specific build, SamplesApp, and generated-file rules before editing framework code.

Public API Coverage

Use curated app-building API guidance first:

• references/00-api-map.md

Use the compact lookup index for common namespaces, packages, source trees, and grep patterns:

• references/api-index.md

For migration work:

• references/24-avalonia-to-uno-migration-guide.md

For Uno framework source-tree work:

• references/25-uno-repo-contributor-lane.md

Execution Rules

• Prefer XAML-first and WinUI-first guidance for production Uno apps.
• Prefer Uno.Sdk project structure and explicit UnoFeatures selection over ad hoc package piles.
• Prefer x:Bind for typed or high-frequency bindings; use {Binding} when a DataContext-driven contract is cleaner.
• Treat renderer choice as an architectural decision, not as a late-stage styling toggle.
• Keep platform-specific code in partial files or conditional XAML, not mixed into shared logic by default.
• For app or library code, use standard WinUI dependency-property and templated-control patterns; reserve Uno's internal GeneratedDependencyProperty workflow for work inside the Uno framework repo itself.
• Check supported features and supported libraries before recommending advanced WinUI or platform APIs.
• Use Hot Reload, Dev Server, and Uno MCP workflows when they shorten the inner loop, but do not make them a hard dependency for the implementation.
• Include end-to-end examples in responses when the user asks for architecture or migration changes.
• If you are editing the Uno source tree itself, follow /Users/wieslawsoltes/GitHub/uno/AGENTS.md first.
• If you are editing the Uno source tree itself, also use the specialized guidance under /Users/wieslawsoltes/GitHub/uno/.github/agents/ for dependency properties, source generators, runtime tests, and WinUI porting.
• For Avalonia-to-Uno migration, anchor decisions in actual Avalonia source and sample patterns from /Users/wieslawsoltes/GitHub/Avalonia/src, /Users/wieslawsoltes/GitHub/Avalonia/samples, and /Users/wieslawsoltes/GitHub/Avalonia/tests, not in generic cross-framework assumptions.