dotnet-quality-ci

Configure .NET CI quality gates covering formatting, analyzers, coverage, mutation testing, and security scanning.

Updated Mar 31, 2026
One-click install
npx skills add https://github.com/zhenpengLai/myuseskill --skill dotnet-quality-ci-zhenpenglai
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: dotnet-quality-ci
Source: https://github.com/zhenpengLai/myuseskill/tree/main/dotnet-quality-ci
Command: npx skills add https://github.com/zhenpengLai/myuseskill --skill dotnet-quality-ci-zhenpenglai

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? .NET repositories often lack a coherent, explicit quality stack in CI: formatting rules drift from .editorconfig, analyzers overlap or go unconfigured, coverage drivers mismatch the test runner, and agents have no documented commands to verify changes. This Skill sets up or refines a complete open-source .NET quality gate stack with clear ownership per gate. ## Core Features & Use Cases - Baseline quality stack setup: Establishes repo-root .editorconfig, dotnet format --verify-no-changes, SDK analyzers with explicit EnableNETAnalyzers and AnalysisLevel, and warning policy in Directory.Build.props. - Tool selection and routing: Chooses third-party analyzers (StyleCopAnalyzers, Roslynator, Meziantou.Analyzer), coverage tooling (coverlet, ReportGenerator), architecture tests (NetArchTest, ArchUnitNET), mutation testing (Stryker.NET), and CodeQL security scanning, routing detailed setup to dedicated tool skills. - Runner-aware configuration: Matches coverage drivers and test commands to the active runner model, VSTest or Microsoft.Testing.Platform, avoiding incompatible switches. - Use Case: A team asks to "define the best OSS CI stack for this .NET repo." The Skill audits current config, picks one owner command per gate category, wires gates into AGENTS.md and GitHub Actions YAML, runs a verification pass, and returns a structured status report. ## Quick Start Ask the agent to set up or audit the .NET quality gates for this repository, covering formatting, analyzers, coverage, and CI workflow configuration.

Frequently Asked Questions about dotnet-quality-ci

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I set up .NET code quality gates in CI?▼

Start with a repo-root .editorconfig, dotnet format --verify-no-changes, and SDK analyzers enabled via EnableNETAnalyzers and AnalysisLevel in Directory.Build.props. Then add coverage, architecture tests, and security scanning as separate gates, each with one explicit owner command documented in AGENTS.md and CI.

What analyzers should I add to a .NET project?▼

Enable the built-in Microsoft.CodeAnalysis.NetAnalyzers first, then add third-party analyzers only where they close a real gap: StyleCopAnalyzers for naming and documentation, Roslynator for broader Roslyn rules, and Meziantou.Analyzer for security and performance. Avoid packages that duplicate SDK analyzer rules.

How do I collect code coverage with Microsoft.Testing.Platform?▼

Microsoft.Testing.Platform projects use coverlet.MTP or MSTest SDK coverage extensions instead of VSTest collectors. Run dotnet test with the MTP coverage flags such as --coverlet, and do not mix VSTest-only switches or .runsettings assumptions into MTP jobs.

Should I use CSharpier or dotnet format for C# formatting?▼

dotnet format is the default owner because it reads .editorconfig and supports CI verification. Use CSharpier only if the repo wants an opinionated formatter, and document explicitly whether it replaces or complements dotnet format to avoid conflicting ownership.

When should I add mutation testing to a .NET repo?▼

Add Stryker.NET once the baseline gates are stable, targeting critical libraries rather than every pull request. Run it on a schedule, document a mutation score threshold, and review reports periodically instead of blocking each PR.

When is this .NET quality skill not applicable?▼

It does not apply to non-.NET repositories, generic CI/CD guidance with no .NET quality stack decisions, or framework-specific test authoring with no quality-gate change. Out-of-scope gates return status not_applicable with an explicit reason.