dotnet-analyzer-config
.NET Analyzer Configuration
Trigger On
- the repo needs a root
.editorconfig - analyzer severity and style ownership are unclear
- the team wants one source of truth for rule configuration
Value
- produce a concrete project delta: code, docs, config, tests, CI, or review artifact
- reduce ambiguity through explicit planning, verification, and final validation skills
- leave reusable project context so future tasks are faster and safer
Do Not Use For
- choosing analyzers with no config change
- formatting-only execution with no config ownership question
Inputs
- the nearest
AGENTS.md - current
.editorconfig - any
Directory.Build.propsoverrides
Quick Start
- Read the nearest
AGENTS.mdand confirm scope and constraints. - Run this skill's
Workflowthrough theRalph Loopuntil outcomes are acceptable. - Return the
Required Result Formatwith concrete artifacts and verification evidence.
Workflow
- Prefer one repo-root
.editorconfigwithroot = true. - Add nested
.editorconfigfiles when a subtree has a clear scoped purpose, such as stricter rules, different generated-code handling, or a different policy for tests or legacy code. - Keep severity in
.editorconfig, not scattered through IDE settings. - Write the file as real EditorConfig, not as a made-up
.NETvariant:- lowercase filename
.editorconfig root = truein the preamble- no inline comments
- forward slashes in globs
- lowercase filename
- Keep bulk switches such as
EnableNETAnalyzersin MSBuild files, not in.editorconfig. - Treat
.globalconfigas an exceptional case, not the normal repo setup.
Bootstrap When Missing
If analyzer configuration is requested but not structured yet:
- Detect current state:
rg --files -g '.editorconfig' -g '.globalconfig'rg -n "EnableNETAnalyzers|AnalysisLevel|AnalysisMode" -g '*.csproj' -g 'Directory.Build.*' .
- Create or normalize one repo-root
.editorconfigwithroot = true. - Move rule severity into
.editorconfigand keep bulk analyzer switches in project or MSBuild config. - Add nested
.editorconfigfiles only when a subtree really needs different scoped policy. - Run
dotnet build SOLUTION_OR_PROJECTand returnstatus: configuredorstatus: improved. - If the repo intentionally uses another documented analyzer-config ownership model, return
status: not_applicable.
Deliver
- one explicit analyzer configuration ownership model
- a root
.editorconfiglayout that agents can extend safely
Validate
- rule severity is reproducible in local and CI builds
- IDE-only settings do not silently override repo policy
- the default path is a root
.editorconfig, not a surprise alternative
Ralph Loop
Use the Ralph Loop for every task, including docs, architecture, testing, and tooling work.
- Plan first (mandatory):
- analyze current state
- define target outcome, constraints, and risks
- write a detailed execution plan
- list final validation skills to run at the end, with order and reason
- Execute one planned step and produce a concrete delta.
- Review the result and capture findings with actionable next fixes.
- Apply fixes in small batches and rerun the relevant checks or review steps.
- Update the plan after each iteration.
- Repeat until outcomes are acceptable or only explicit exceptions remain.
- If a dependency is missing, bootstrap it or return
status: not_applicablewith explicit reason and fallback path.
Required Result Format
status:complete|clean|improved|configured|not_applicable|blockedplan: concise plan and current iteration stepactions_taken: concrete changes madevalidation_skills: final skills run, or skipped with reasonsverification: commands, checks, or review evidence summaryremaining: top unresolved items ornone
For setup-only requests with no execution, return status: configured and exact next commands.
Load References
references/analyzer-config.mdreferences/template.mdreferences/rules.md
Example Requests
- "Make
.editorconfigthe source of truth." - "Write a proper root
.editorconfigfor this repo." - "Fix conflicting analyzer severities in this .NET repo."
More from managedcode/dotnet-skills
dotnet
Primary router skill for broad .NET work. Classify the repo by app model and cross-cutting concern first, then switch to the narrowest matching .NET skill instead of staying at a generic layer.
17dotnet-aspnet-core
Build, debug, modernize, or review ASP.NET Core applications with correct hosting, middleware, security, configuration, logging, and deployment patterns on current .NET.
13dotnet-entity-framework-core
Design, tune, or review EF Core data access with proper modeling, migrations, query translation, performance, and lifetime management for modern .NET applications.
12dotnet-code-review
Review .NET changes for bugs, regressions, architectural drift, missing tests, incorrect async or disposal behavior, and platform-specific pitfalls before you approve or merge them.
11dotnet-architecture
Design or review .NET solution architecture across modular monoliths, clean architecture, vertical slices, microservices, DDD, CQRS, and cloud-native boundaries without over-engineering.
11dotnet-signalr
Implement or review SignalR hubs, streaming, reconnection, transport, and real-time delivery patterns in ASP.NET Core applications.
10