.NET Quality CI

Trigger On

• adding or tightening .NET code-quality gates in CI
• choosing analyzers, coverage, mutation, or architecture-test tooling for a .NET repo
• standardizing .editorconfig, dotnet format, and warning policy

Workflow

1. Start with the repo-native baseline:

- repo-root .editorconfig - dotnet format --verify-no-changes - SDK analyzers with explicit EnableNETAnalyzers, AnalysisLevel, and warning policy

1. Add third-party analyzers only where they close a real gap:

- StyleCopAnalyzers - Roslynator - Meziantou.Analyzer - framework analyzers such as xUnit, MSTest, or TUnit analyzers

1. Separate quality gates by purpose:

- formatting and style - correctness and static analysis - coverage and reports - architecture rules - security scanning - mutation testing

1. For complexity, use a composite approach:

- CA1502 thresholding - maintainability limits in AGENTS.md - architecture tests - coverage and mutation where risk justifies it

1. Make ownership explicit in AGENTS.md and CI:

- which command formats - which command analyzes - which command measures coverage - which runner model the tests use

1. After any .NET code change, the repo's quality pass must be runnable by agents:

- format - build - analyze - focused tests - broader tests - coverage and report generation when configured - extra configured gates only when the repo actually enabled them

1. Route tool-specific setup through dedicated skills where possible:

- dotnet-format - dotnet-code-analysis - dotnet-analyzer-config - analyzer-pack skills such as dotnet-stylecop-analyzers, dotnet-roslynator, and dotnet-meziantou-analyzer - frontend asset quality skills in mixed .NET plus Node repos such as dotnet-eslint, dotnet-stylelint, dotnet-htmlhint, dotnet-webhint, dotnet-biome, dotnet-sonarjs, dotnet-metalint, and dotnet-chous - coverage/reporting skills such as dotnet-coverlet and dotnet-reportgenerator - architecture/security skills such as dotnet-netarchtest, dotnet-archunitnet, and dotnet-codeql

1. Avoid overlapping tools with conflicting ownership. If you add an opinionated formatter, define whether it replaces or complements dotnet format.

Deliver

• a documented .NET quality baseline
• CI commands that are explicit and reproducible
• analyzer and coverage choices that match the repo's runner model
• a documented post-change quality pass for agents and CI
• tool selection that stays open-source and free by default, with caveats called out explicitly

Validate

• repo-root .editorconfig is the default source of truth for per-rule severity
• formatting, analyzer, and coverage commands are runner-compatible
• added tools cover distinct gaps instead of duplicating each other
• complexity and architecture policy are explicit, not implied
• .NET code changes are expected to pass more than tests alone when quality gates are configured
• any licensing or hosting caveat is documented before the tool becomes a default gate

Load References

Related skills

Related agents