Starting project setup before the setup-and-scaffold flow in this skill has finished.
Starting with unpackaged deployment unless the user needs repeatable CLI launch, an installer, existing desktop app integration, or a deliberate runtime strategy.
Giving machine-readiness advice without verification.
Treating old Windows builds, missing SDKs, or partial Visual Studio installs as “probably fine.”
Deferring the packaging choice until after startup, storage, and launch code are already written.
Choose packaged when the user wants the default WinUI 3 path, easy local F5 workflows, or Store-friendly deployment. Keep the scaffold at its default unless the user explicitly asks for unpackaged behavior.
Choose packaged when the app needs package identity or package-backed APIs during normal operation.
Choose unpackaged when the user expects direct .exe launches, agent-driven local verification after each change, or integration with an existing installer or external location. Request that option through the setup flow instead of converting the initial project afterward.
For either packaging model, scaffold first through the setup flow in SKILL.md and continue from the generated project instead of copying in prebuilt baseline files.
If startup or shared resources later become suspect, create a fresh comparison app with the same packaging model and diff against that dotnet new winui output before broader restructuring.
Once the model is chosen, keep startup and service code consistent with that model.
Choose the standard blank app template first, then layer in navigation, title bar, or windowing patterns as the app matures.