All skills
openai avatar

/winui-app

@c207989 official
by openaiopenai/skills28k stars
1,891

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 app design and development work.

Use this Skill: https://skilld.dev/gh/openai/skills/winui-app

This session only. Nothing lands on disk.

referencesshell-navigation-and-windowing.md

≈888 tokens on demand. Your agent reads this file only when SKILL.md points to it.

What This Reference Is For

Use this file for top-level app shells, page navigation models, custom title bars, and multi-window decisions.

Prefer

  • NavigationView for standard desktop shells with clear top-level destinations.
  • A small, stable set of primary destinations.
  • Built-in back navigation behavior that matches user expectations.
  • AppWindow and Windows App SDK windowing APIs for modern window management.

Avoid

  • Overloading the nav surface with every command and secondary action.
  • Turning the NavigationView pane into a branded hero area when the user did not ask for custom shell treatment.
  • Custom title bar layouts that break drag regions or caption button clarity.
  • Multi-window designs unless the workflow clearly benefits from them.

Navigation Guidance

  • Use left navigation when the app has several stable, high-level destinations.
  • Use top navigation when there are few peer destinations and width is available.
  • Use a single-page or document-first layout when navigation is shallow and the user mostly stays in one workflow.
  • Keep naming and iconography stable across pages.
  • Treat NavigationView as functional shell chrome first. Keep pane headers, footer content, and decorative branding minimal unless the product requirements clearly call for them.
  • Prefer the platform's normal pane structure before adding custom logo blocks, taglines, or non-navigation content that changes the shell's native feel.
  • For narrow or phone-like widths, stop reserving permanent pane width for desktop navigation. Prefer a minimal or overlay navigation mode, show the pane toggle when needed, close the pane by default after navigation, and give content the width back.
  • When a shell enters a phone-width mode, reduce content padding and decorative chrome so the page reads as one primary column instead of a desktop shell with a squeezed content strip.

Title Bar Guidance

  • Treat the title bar as functional chrome first, branding surface second.
  • Keep empty non-interactive areas draggable.
  • Blend title bar visuals with the rest of the app when possible.
  • Respect light, dark, and high-contrast states.

Windowing Guidance

  • Start with one main window.
  • Add secondary windows only for workflows such as document detachment, inspection panes, or tool windows.
  • Use Windows App SDK samples for resizing, placement, and window-specific behaviors instead of inventing custom platform abstractions.

Sample and Source Anchors

  • WinUI Gallery NavigationView, TitleBar, AppWindow, and windowing sample pages
  • WindowsAppSDK-Samples Samples/Windowing
  • Learn navigation and title bar guidance

Review Checklist

  • Is the navigation model simple and intentional?
  • Does the shell still look and behave like a normal WinUI NavigationView unless there is an explicit reason to diverge?
  • Does the title bar still behave like a Windows title bar?
  • Are back, search, and pane behaviors consistent?
  • Is multi-window use justified by the workflow?
  • Does the shell intentionally switch behavior at narrow or phone widths instead of leaving a full desktop pane open?

Source: SKILL.md on GitHub

No alerts17d5 checks · Risk SAFE
  • Gen Agent Trust Hub17d

    This skill provides guidance and scaffolding patterns for building WinUI 3 desktop applications with the Windows App SDK. It includes standard platform configuration and setup mechanisms that leverage official Windows tools. While it executes configuration scripts to configure the local environment, these are implemented via native tools such as WinGet according to official Microsoft workflows.

  • Socket17d

    No alerts

  • Snyk17d

    Risk: LOW · No issues

  • Runlayer6mo

    5/20 files flagged

  • ZeroLeaks5mo

    Score: 93/100 · 2 sections analyzed

Signed by skilld at c207989. This ties the file your Agent reads to that commit on GitHub. It does not review the instructions.

Last checked against GitHub 2 months ago.

Activeupdated 7 months ago
  • winui
  • csharp
  • windows-app-sdk
  • desktop
  • xaml
  • visual-studio
  • winget
  • theming
  • accessibility
  • responsive-design

README badge

README badge for openai/skills/winui-app

Bootstraps and develops WinUI 3 desktop applications in C# using the Windows App SDK, with guidance for environment setup, project scaffolding, XAML patterns, controls, navigation, theming, and deployment. Use this skill when creating a new app, preparing a machine for WinUI development, or troubleshooting XAML compilation and startup issues.

Generated from the current SKILL.md.

Does this skill work with C++ or only C#?
The skill is built around C# and the Windows App SDK. C++ or C++/WinRT is mentioned only when the difference is material to the task.
Can I use this skill to set up an unpackaged app instead of a packaged one?
Yes. The skill supports both packaged and unpackaged app models. You can pass the `--unpackaged` flag to `dotnet new winui`, or the skill will default to packaged for Store-like workflows and unpackaged for CLI build-and-run loops.
What if my machine isn't ready for WinUI development yet?
The skill includes a bundled WinGet configuration (`config.yaml`) that installs Visual Studio Community 2026, enables Developer Mode, and adds the required Windows App SDK C# components. For diagnostics-only audits without machine changes, the skill provides manual verification guidance instead.
Does this skill handle third-party component libraries or only native WinUI controls?
The skill favors native WinUI controls and Fluent styling first. It uses the CommunityToolkit only when built-in controls do not cover the need cleanly, and avoids inventing custom component libraries unless you explicitly request them.

Generated from the current SKILL.md. These answers refresh after source changes.