.NET Roslyn Analyzer Rollout

Turns on .NET Roslyn analyzers for an existing solution in stages, then works through the warnings they raise.

You get three things: one AnalysisMode setting in one file, an .editorconfig block that sets the severity of 24 named analyzer IDs, and a triage list that puts every unique warning in one of three buckets: fix now, suppress with a stated reason, or backlog.

Use when you want to enable, roll out or tighten .NET analyzers or AnalysisMode, want a build that reports code-quality warnings, or want the warnings from an analyzer pass triaged.

Do not use for a best-practice audit of the code (use the .NET Best Practice Checker), IDE style rules (IDE*), or non-.NET projects.

How it works

1. Survey, read-only. Finds the solution and project files and reads Directory.Build.props, global.json and every .editorconfig. It notes existing analyzer settings and keeps them.
2. Choose the mode. Defaults to Recommended. A project that sets its own AnalysisMode wins over Directory.Build.props, so the skill reports it and asks.
3. Propose, then write. Shows the exact files and asks once. Nothing is written until you say yes, and a yes to one write does not cover the next.
4. Build. Asks first, then runs dotnet build --no-incremental and saves the full output.
5. Triage. Deduplicates on file, line, column and ID, reads the code around each warning, and assigns a bucket.
6. Apply and rebuild. Makes the fix-now edits and the suppressions you approved, rebuilds, and compares before and after.
7. Report. Lists every write, every build, and everything it did not run.

Rules it keeps

• Severity is written by ID, one dotnet_diagnostic.<ID>.severity line per rule. No bulk entries.
• Every suppression carries a reason that names the constraint.
• EF1002, EF1003, CA5359 and CA5399 are suppressed only on your explicit decision.
• A build that fails, or a project that does not run analyzers, goes under "Not checked" with the first error line.

What is in the package

Markdown only, no scripts: SKILL.md, six reference files (analysis mode, .editorconfig severities, build and capture, the 24 analyzer IDs, triage, report template), and docs/VALIDATION.md with the recorded run and its full build logs.

Tested

One run on a synthetic two-project solution, .NET SDK 10.0.402, Windows 11. Before triage the build reported 44 unique analyzer positions; after triage it reported 39. Five positions went away: four fixed (CA1849, CA2200, EF1002, EF1003) and one suppressed with a reason (CA1031). The other 39 stayed as backlog. Both builds exited 0. Eight probe builds of the same solution tried other settings: None, Default, Recommended and All, .editorconfig entries, and an incremental build.

Not tested: real projects, multi-target projects or targets older than .NET 5, EnableNETAnalyzers, Linux and macOS, other SDK versions, and the EF Core fixes against a database. docs/VALIDATION.md lists these and records one place where the observed behavior conflicts with Microsoft's documentation (bulk .editorconfig entries).

Limitations

• It cites rules for 24 analyzer IDs. Any other warning goes through the same three buckets, but the skill makes no claim about those rules.
• Tuned and tested on one synthetic solution I wrote. How it behaves on a large real solution is unknown.
• Each warning is read in context before it is bucketed, so a solution with thousands of warnings takes a long session.

Requirements

• An agent that reads skill folders and has file read and search tools (tested only in Claude Code, Windows).
• The .NET SDK, for the build step.
• No API keys, accounts or environment variables.

Network and external references (disclosure)

• The skill itself makes no network calls and sends no repository content anywhere.
• dotnet build restores packages from the NuGet feeds in your repo's configuration and writes bin/ and obj/. The skill asks first.