winui-dev-workflow + winui-code-review: seed canonical .editorconfig and run style polish pass on greenfield apps

97: #97

Problem

From Joe's blog post:

One thing I didn't expect: a greenfield app has no existing style to follow, so the skill just made its own choices. Fair enough. But when I opened the generated code in Visual Studio, it was immediately lit up with hints and suggestions to change things. Formatting, naming conventions, the usual.

It's not a big deal, nothing broken. But it's a little odd that Microsoft's own skill would produce code that Microsoft's own IDE immediately flags. For a brand new project where there's no legacy style to preserve, you'd think they'd at least agree on what "correct" looks like.

winui-code-review/references/quality-rules.md already references applying IDE0001–IDE0090, but only as a review-time check. Greenfield projects ship with no .editorconfig and no style polish pass, so the result lights up Visual Studio the moment it opens.

This is low-stakes individually but high-signal as polish — the blog calls it out by name, and "Microsoft's skill produces code Microsoft's IDE complains about" is exactly the kind of friction that erodes trust in the rest of the experience.

Proposed fix

Two-part:

1. Seed .editorconfig at scaffold (winui-dev-workflow) — ship a canonical, VS-clean .editorconfig as part of the skill payload, and drop it into the new project root during scaffolding. Align it with WindowsAppSDK / Community Toolkit house style. Goal: scaffold + open in VS = zero IDE hints on the template's own output.

2. Greenfield style polish pass (winui-code-review or a new sub-skill) — after first successful build, run dotnet format plus the safe subset of IDE0001–IDE0090 autofixes. Idempotent. Either explicitly invoked or wired into the autopilot greenfield path.

For existing projects: the skill must defer to the existing .editorconfig and never overwrite. Only seeds the file if one doesn't already exist.

Related

May be subsumed by — or coordinated with — a unified "greenfield polish phase" step (see cross-cutting themes on the 97 issue).

Acceptance criteria

• Canonical .editorconfig checked in under the skill payload.
• Scaffolding a fresh app and opening in VS shows zero IDE hints on the template's own code.
• dotnet format against the scaffold is a no-op (proves alignment between the seeded .editorconfig and what the agent emits).
• Documented behavior for existing apps: defer to existing .editorconfig, never overwrite.

Acknowledgments

Identified by Joe Finney in Building Fluent Icon Finder with the WinUI Copilot skill.

Start with winui-code-review/references/quality-rules.md and the winui-dev-workflow scaffold path to determine where the canonical .editorconfig belongs and how existing files are detected. Validate a fresh app by opening it in Visual Studio and running dotnet format; done means the format check is a no-op, template code has no IDE hints, and existing .editorconfig files are never overwritten.