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:
-
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.
-
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
Acknowledgments
Identified by Joe Finney in Building Fluent Icon Finder with the WinUI Copilot skill.
97: #97
Problem
From Joe's blog post:
winui-code-review/references/quality-rules.mdalready references applyingIDE0001–IDE0090, but only as a review-time check. Greenfield projects ship with no.editorconfigand 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:
Seed
.editorconfigat scaffold (winui-dev-workflow) — ship a canonical, VS-clean.editorconfigas 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.Greenfield style polish pass (
winui-code-reviewor a new sub-skill) — after first successful build, rundotnet formatplus the safe subset ofIDE0001–IDE0090autofixes. Idempotent. Either explicitly invoked or wired into the autopilot greenfield path.For existing projects: the skill must defer to the existing
.editorconfigand 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
.editorconfigchecked in under the skill payload.dotnet formatagainst the scaffold is a no-op (proves alignment between the seeded.editorconfigand what the agent emits)..editorconfig, never overwrite.Acknowledgments
Identified by Joe Finney in Building Fluent Icon Finder with the WinUI Copilot skill.