analyzer-config

Configures .NET analyzer and style rule severity through a repo-root .editorconfig file.

Updated May 2, 2026
One-click install
npx skills add https://github.com/hdeshev/pi-config --skill analyzer-config-hdeshev
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: analyzer-config
Source: https://github.com/hdeshev/pi-config/tree/main/agent/skills/analyzer-config
Command: npx skills add https://github.com/hdeshev/pi-config --skill analyzer-config-hdeshev

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? .NET repositories often have analyzer severity scattered across IDE settings, MSBuild files, and ad-hoc configs, making rule ownership unclear and builds inconsistent between local and CI environments. This Skill establishes a single repo-root .editorconfig as the source of truth for analyzer and code-style rules. ## Core Features & Use Cases - Root .editorconfig Setup: Creates or normalizes one repo-root .editorconfig with root = true, correct EditorConfig syntax, and proper section layout. - Rule Severity Configuration: Moves dotnet_diagnostic severities and code-style options into .editorconfig while keeping bulk switches like EnableNETAnalyzers in MSBuild files. - Scoped Nested Configs: Adds nested .editorconfig files only when a subtree genuinely needs different policy, such as generated code, tests, or legacy modules. - Use Case: A team inherits a .NET repo with conflicting analyzer severities between Visual Studio and CI. Use this Skill to consolidate all rule configuration into a versioned root .editorconfig, then verify with dotnet build. ## Quick Start Ask the agent to make .editorconfig the source of truth for analyzer rules in this .NET repository and verify the result with a build.

Frequently Asked Questions about analyzer-config

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

FAQPage Schema
How do I configure .NET analyzer severity in .editorconfig?▼

Set dotnet_diagnostic.RULEID.severity entries under a matching section like [*.cs] in a repo-root .editorconfig with root = true. Use values such as warning, error, suggestion, or none, and keep bulk switches like EnableNETAnalyzers in MSBuild files instead.

What is the difference between .editorconfig and .globalconfig for analyzers?▼

A repo-root .editorconfig uses file-tree inheritance and is the recommended default for normal .NET repos. .globalconfig is an exceptional case for analyzer config distributed by packages or SDK conventions where file-tree inheritance does not fit.

Can I use nested .editorconfig files in a .NET repo?▼

Yes, add a nested .editorconfig when a subtree has a clear scoped purpose, such as stricter rules in a core domain, relaxed rules for generated code, or different test conventions. Closer files override parent rules for matching sections.

Why are inline comments a problem in .editorconfig files?▼

The EditorConfig specification does not support inline comments; comments must be on their own line starting with # or ;. A trailing comment after a severity value becomes part of the value and can break rule parsing.

When should I not use a root .editorconfig for analyzer rules?▼

Avoid it when the repo intentionally stores analyzer policy only in IDE profiles or ephemeral local settings, or when choosing analyzers without any config change. It is also unnecessary for formatting-only execution with no config ownership question.