dotnet-stylecop-analyzers
Use the open-source free `StyleCop.Analyzers` package for naming, layout, documentation, and style rules in .NET projects. Use when a repo wants stricter style conventions than the SDK analyzers alone provide.
Install
npx skills add https://github.com/Postpartum-genushyacinthus29/dotnet-skills/tree/main/skills/dotnet-stylecop-analyzers
claude plugin marketplace add https://llmmart.ai/marketplace.json && claude plugin install postpartum-genushyacinthus29-dotnet-skills@llmmart
git clone https://github.com/Postpartum-genushyacinthus29/dotnet-skills.git
The skills CLI installs just this skill, for any of its supported agents. Claude Code installs the whole postpartum-genushyacinthus29/dotnet-skills collection as a plugin from our marketplace. Git is the plain clone.
Skill manifest
StyleCop Analyzers
Trigger On
- the repo wants
StyleCop.Analyzers - naming, layout, or documentation style needs stronger enforcement
- the team needs
stylecop.jsonguidance
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
- repos that intentionally rely only on SDK analyzers
- repos where
StyleCopoverlaps too heavily with an existing style package and no consolidation is planned
Inputs
- the nearest
AGENTS.md - current
.editorconfig - any existing
stylecop.json
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
- Add
StyleCop.Analyzersonly if the repo wants its opinionated style rules. - Keep severity in the root
.editorconfig. - Use
stylecop.jsononly for StyleCop-specific behavioral options. - Prefer one checked-in
stylecop.jsonper repo unless a project genuinely needs its own behavior. - Avoid rule duplication with SDK analyzers or other analyzer packs when possible.
Bootstrap When Missing
If StyleCop.Analyzers is not configured yet:
- Detect current state:
rg -n "StyleCop\\.Analyzers|stylecop\\.json" -g '*.csproj' -g 'stylecop.json' .
- Add package to the intended scope:
dotnet add PROJECT.csproj package StyleCop.Analyzers
- Keep severity in root
.editorconfigand usestylecop.jsononly for StyleCop-specific behavior. - Prevent overlap with existing analyzer packs by defining ownership.
- Run
dotnet build SOLUTION_OR_PROJECTand returnstatus: configuredorstatus: improved. - If the repo intentionally uses SDK analyzers only, return
status: not_applicable.
Deliver
- explicit StyleCop package setup
- repo-owned StyleCop rule configuration
- clear split between root
.editorconfigandstylecop.json
Validate
- StyleCop severity is versioned in repo config
stylecop.jsonis used only where it adds value
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/stylecop-analyzers.mdreferences/rules.mdreferences/config.md
Example Requests
- "Add
StyleCop.Analyzersto this solution." - "Configure StyleCop without losing
.editorconfigownership."
Files (dotnet-skills)
-
references
-
config.md 8.7 KB
# StyleCop Analyzers Configuration Reference ## Configuration Files StyleCop Analyzers uses two configuration sources: | File | Purpose | |------|---------| | `.editorconfig` | Rule severity, enable/disable rules | | `stylecop.json` | StyleCop-specific behavioral settings | ## stylecop.json Schema Always include the schema reference for IDE support: ```json { "$schema": "https://raw.githubusercontent.com/DotNetAnalyzers/StyleCopAnalyzers/master/StyleCop.Analyzers/StyleCop.Analyzers/Settings/stylecop.schema.json", "settings": { // Configuration sections go here } } ``` ## Configuration Sections ### documentationRules Controls XML documentation behavior. ```json { "settings": { "documentationRules": { "companyName": "Your Company", "copyrightText": "Copyright (c) {companyName}. All rights reserved.", "headerDecoration": "-----------------------------------------------------------------------", "documentExposedElements": true, "documentInternalElements": false, "documentPrivateElements": false, "documentInterfaces": true, "documentPrivateFields": false, "fileNamingConvention": "stylecop", "xmlHeader": false, "variables": { "customVariable": "value" }, "excludeFromPunctuationCheck": ["seealso", "typeparam"] } } } ``` | Setting | Type | Default | Description | |---------|------|---------|-------------| | companyName | string | "PlaceholderCompany" | Company name for file headers | | copyrightText | string | varies | Copyright text template | | headerDecoration | string | null | Decoration line for headers | | documentExposedElements | bool | true | Require docs on public members | | documentInternalElements | bool | true | Require docs on internal members | | documentPrivateElements | bool | false | Require docs on private members | | documentInterfaces | bool | true | Require docs on interface members | | documentPrivateFields | bool | false | Require docs on private fields | | fileNamingConvention | string | "stylecop" | "stylecop" or "metadata" | | xmlHeader | bool | true | Use XML-style file headers | | variables | object | {} | Custom variables for templates | | excludeFromPunctuationCheck | array | [] | Tags exempt from SA1629 | ### orderingRules Controls using directive and element ordering. ```json { "settings": { "orderingRules": { "usingDirectivesPlacement": "outsideNamespace", "systemUsingDirectivesFirst": true, "blankLinesBetweenUsingGroups": "require", "elementOrder": [ "kind", "accessibility", "constant", "static", "readonly" ] } } } ``` | Setting | Type | Values | Description | |---------|------|--------|-------------| | usingDirectivesPlacement | string | "insideNamespace", "outsideNamespace", "preserve" | Using directive location | | systemUsingDirectivesFirst | bool | true/false | System usings first | | blankLinesBetweenUsingGroups | string | "allow", "require", "omit" | Blank lines between groups | | elementOrder | array | ordering specifiers | Member ordering within types | ### namingRules Controls naming convention enforcement. ```json { "settings": { "namingRules": { "allowCommonHungarianPrefixes": true, "allowedHungarianPrefixes": ["ui", "db"], "allowedNamespaceComponents": ["eBay", "iPhone"], "includeInferredTupleElementNames": false, "tupleElementNameCasing": "camelCase" } } } ``` | Setting | Type | Default | Description | |---------|------|---------|-------------| | allowCommonHungarianPrefixes | bool | true | Allow common prefixes like "is" | | allowedHungarianPrefixes | array | [] | Additional allowed prefixes | | allowedNamespaceComponents | array | [] | Namespace parts exempt from casing | | includeInferredTupleElementNames | bool | false | Check inferred tuple names | | tupleElementNameCasing | string | "camelCase" | Tuple element casing | ### layoutRules Controls file and code layout. ```json { "settings": { "layoutRules": { "newlineAtEndOfFile": "require", "allowConsecutiveUsings": true, "allowDoWhileOnClosingBrace": false } } } ``` | Setting | Type | Values | Description | |---------|------|--------|-------------| | newlineAtEndOfFile | string | "allow", "require", "omit" | Trailing newline policy | | allowConsecutiveUsings | bool | true/false | Allow `using` blocks without braces | | allowDoWhileOnClosingBrace | bool | false/true | `while` on same line as `}` | ### readabilityRules Controls readability enforcement. ```json { "settings": { "readabilityRules": { "allowBuiltInTypeAliases": false } } } ``` | Setting | Type | Default | Description | |---------|------|---------|-------------| | allowBuiltInTypeAliases | bool | false | Allow `int` vs `Int32` mixing | ### indentation (deprecated) Note: Indentation settings were deprecated. Use `.editorconfig` for indentation. ```json { "settings": { "indentation": { "indentationSize": 4, "tabSize": 4, "useTabs": false } } } ``` ## Complete stylecop.json Examples ### Minimal Configuration ```json { "$schema": "https://raw.githubusercontent.com/DotNetAnalyzers/StyleCopAnalyzers/master/StyleCop.Analyzers/StyleCop.Analyzers/Settings/stylecop.schema.json", "settings": { "orderingRules": { "usingDirectivesPlacement": "outsideNamespace" }, "layoutRules": { "newlineAtEndOfFile": "require" } } } ``` ### Open Source Project ```json { "$schema": "https://raw.githubusercontent.com/DotNetAnalyzers/StyleCopAnalyzers/master/StyleCop.Analyzers/StyleCop.Analyzers/Settings/stylecop.schema.json", "settings": { "documentationRules": { "companyName": "Project Contributors", "copyrightText": "Licensed under the MIT License. See LICENSE in the project root.", "documentExposedElements": true, "documentInternalElements": false, "xmlHeader": false }, "orderingRules": { "usingDirectivesPlacement": "outsideNamespace", "systemUsingDirectivesFirst": true, "blankLinesBetweenUsingGroups": "require" }, "layoutRules": { "newlineAtEndOfFile": "require" } } } ``` ### Enterprise Project ```json { "$schema": "https://raw.githubusercontent.com/DotNetAnalyzers/StyleCopAnalyzers/master/StyleCop.Analyzers/StyleCop.Analyzers/Settings/stylecop.schema.json", "settings": { "documentationRules": { "companyName": "Contoso Corporation", "copyrightText": "Copyright (c) {companyName}. All rights reserved.\nLicensed under the Contoso Enterprise License.", "headerDecoration": "-----------------------------------------------------------------------", "documentExposedElements": true, "documentInternalElements": true, "documentInterfaces": true, "xmlHeader": true }, "orderingRules": { "usingDirectivesPlacement": "outsideNamespace", "systemUsingDirectivesFirst": true, "blankLinesBetweenUsingGroups": "require", "elementOrder": [ "kind", "accessibility", "constant", "static", "readonly" ] }, "namingRules": { "allowCommonHungarianPrefixes": false }, "layoutRules": { "newlineAtEndOfFile": "require" } } } ``` ## Project Integration ### Add to Project File Link `stylecop.json` as an additional file: ```xml <ItemGroup> <AdditionalFiles Include="$(MSBuildThisFileDirectory)stylecop.json" Link="stylecop.json" /> </ItemGroup> ``` ### Add to Directory.Build.props For solution-wide configuration: ```xml <Project> <ItemGroup> <AdditionalFiles Include="$(MSBuildThisFileDirectory)stylecop.json" Link="stylecop.json" /> </ItemGroup> </Project> ``` ### Multiple Configuration Files For project-specific overrides: ```xml <!-- In a specific project --> <ItemGroup> <AdditionalFiles Remove="$(MSBuildThisFileDirectory)stylecop.json" /> <AdditionalFiles Include="stylecop.project.json" Link="stylecop.json" /> </ItemGroup> ``` ## Configuration Precedence 1. Project-specific `stylecop.json` 2. Directory-level `stylecop.json` via Directory.Build.props 3. Root `stylecop.json` 4. Default StyleCop Analyzers settings Rule severity always comes from `.editorconfig`, not `stylecop.json`. ## Validation Validate configuration with schema: ```bash # Check JSON syntax python3 -c "import json; json.load(open('stylecop.json'))" ``` The schema URL provides IDE validation in VS Code, Visual Studio, and JetBrains Rider. ## Sources - [StyleCop Analyzers Configuration](https://github.com/DotNetAnalyzers/StyleCopAnalyzers/blob/master/documentation/Configuration.md) - [stylecop.json Schema](https://raw.githubusercontent.com/DotNetAnalyzers/StyleCopAnalyzers/master/StyleCop.Analyzers/StyleCop.Analyzers/Settings/stylecop.schema.json) -
rules.md 8.6 KB
# StyleCop Analyzers Rules Reference ## Rule Categories StyleCop Analyzers organizes rules into these categories: | Prefix | Category | Description | |--------|----------|-------------| | SA0xxx | Special Rules | Analyzer configuration and suppression | | SA1xxx | Spacing Rules | Whitespace and spacing conventions | | SA12xx | Readability Rules | Code readability and clarity | | SA13xx | Ordering Rules | Element and using directive ordering | | SA14xx | Maintainability Rules | Code maintainability patterns | | SA15xx | Layout Rules | File and element layout conventions | | SA16xx | Documentation Rules | XML documentation requirements | | SA17xx | Naming Rules | Naming conventions | | SX1xxx | Alternative Rules | Alternative versions of existing rules | ## Commonly Adjusted Rules ### Spacing Rules (SA1xxx) | Rule | Description | Common Setting | |------|-------------|----------------| | SA1000 | Keywords should be spaced correctly | warning | | SA1001 | Commas should be spaced correctly | warning | | SA1005 | Single-line comments should begin with space | warning | | SA1009 | Closing parenthesis should be spaced correctly | warning | | SA1011 | Closing square brackets should be spaced correctly | warning | | SA1028 | Code should not contain trailing whitespace | warning | ### Readability Rules (SA12xx) | Rule | Description | Common Setting | |------|-------------|----------------| | SA1101 | Prefix local calls with this | none (often disabled) | | SA1116 | Split parameters should start on line after declaration | warning | | SA1117 | Parameters should be on same line or separate lines | warning | | SA1118 | Parameter should not span multiple lines | suggestion | | SA1122 | Use string.Empty for empty strings | warning | | SA1127 | Generic type constraints should be on their own line | warning | | SA1128 | Put constructor initializers on their own line | warning | | SA1133 | Do not combine attributes | suggestion | ### Ordering Rules (SA13xx) | Rule | Description | Common Setting | |------|-------------|----------------| | SA1200 | Using directives should be placed correctly | warning | | SA1201 | Elements should appear in the correct order | warning | | SA1202 | Elements should be ordered by access | warning | | SA1203 | Constants should appear before fields | warning | | SA1204 | Static elements should appear before instance elements | warning | | SA1208 | System using directives should be placed before other usings | warning | | SA1210 | Using directives should be ordered alphabetically | suggestion | | SA1211 | Using alias directives should be ordered alphabetically | suggestion | ### Maintainability Rules (SA14xx) | Rule | Description | Common Setting | |------|-------------|----------------| | SA1400 | Access modifier should be declared | warning | | SA1401 | Fields should be private | warning | | SA1402 | File may only contain a single type | warning | | SA1403 | File may only contain a single namespace | warning | | SA1404 | Code analysis suppression should have justification | warning | | SA1405 | Debug.Assert should provide message text | suggestion | | SA1413 | Use trailing comma in multi-line initializers | none (often disabled) | ### Layout Rules (SA15xx) | Rule | Description | Common Setting | |------|-------------|----------------| | SA1500 | Braces for multi-line statements should not share line | warning | | SA1501 | Statement should not be on a single line | warning | | SA1502 | Element should not be on a single line | suggestion | | SA1503 | Braces should not be omitted | warning | | SA1504 | All accessors should be single-line or multi-line | warning | | SA1505 | Opening braces should not be followed by blank line | warning | | SA1508 | Closing braces should not be preceded by blank line | warning | | SA1512 | Single-line comments should not be followed by blank line | none (often disabled) | | SA1515 | Single-line comment should be preceded by blank line | none (often disabled) | | SA1516 | Elements should be separated by blank line | warning | | SA1519 | Braces should not be omitted from multi-line child statement | warning | ### Documentation Rules (SA16xx) | Rule | Description | Common Setting | |------|-------------|----------------| | SA1600 | Elements should be documented | none or suggestion | | SA1601 | Partial elements should be documented | none | | SA1602 | Enumeration items should be documented | none or suggestion | | SA1604 | Element documentation should have summary | warning | | SA1611 | Element parameters should be documented | suggestion | | SA1614 | Element parameter documentation should have text | suggestion | | SA1615 | Element return value should be documented | suggestion | | SA1618 | Generic type parameters should be documented | suggestion | | SA1623 | Property summary documentation should match accessors | warning | | SA1629 | Documentation text should end with a period | suggestion | | SA1633 | File should have header | none (often disabled) | | SA1634 | File header should show copyright text | none | | SA1649 | File name should match first type name | warning | ### Naming Rules (SA17xx) | Rule | Description | Common Setting | |------|-------------|----------------| | SA1300 | Element should begin with upper-case letter | warning | | SA1302 | Interface names should begin with I | warning | | SA1303 | Const field names should begin with upper-case letter | warning | | SA1304 | Non-private readonly fields should begin with upper-case letter | warning | | SA1306 | Field names should begin with lower-case letter | warning | | SA1307 | Accessible fields should begin with upper-case letter | warning | | SA1309 | Field names should not begin with underscore | warning or none | | SA1310 | Field names should not contain underscore | warning | | SA1311 | Static readonly fields should begin with upper-case letter | warning | ## Alternative Rules (SXxxxx) | Rule | Description | Use Case | |------|-------------|----------| | SX1101 | Do not prefix local calls with this | Alternative to SA1101 | | SX1309 | Field names should begin with underscore | For `_field` convention | | SX1309S | Static field names should begin with underscore | For `_staticField` convention | ## .editorconfig Configuration Examples ### Minimal Enforcement ```ini [*.cs] # Disable verbose documentation requirements dotnet_diagnostic.SA1600.severity = none dotnet_diagnostic.SA1601.severity = none dotnet_diagnostic.SA1602.severity = none dotnet_diagnostic.SA1633.severity = none # Disable this-prefix requirement dotnet_diagnostic.SA1101.severity = none # Allow underscore prefix for fields dotnet_diagnostic.SA1309.severity = none ``` ### Strict Enforcement ```ini [*.cs] # Enable most rules as warnings dotnet_analyzer_diagnostic.category-StyleCop.CSharp.DocumentationRules.severity = warning dotnet_analyzer_diagnostic.category-StyleCop.CSharp.LayoutRules.severity = warning dotnet_analyzer_diagnostic.category-StyleCop.CSharp.MaintainabilityRules.severity = warning dotnet_analyzer_diagnostic.category-StyleCop.CSharp.NamingRules.severity = warning dotnet_analyzer_diagnostic.category-StyleCop.CSharp.OrderingRules.severity = warning dotnet_analyzer_diagnostic.category-StyleCop.CSharp.ReadabilityRules.severity = warning dotnet_analyzer_diagnostic.category-StyleCop.CSharp.SpacingRules.severity = warning # Exceptions dotnet_diagnostic.SA1101.severity = none dotnet_diagnostic.SA1633.severity = none ``` ### Common Rule Combinations For teams using underscore-prefixed private fields: ```ini [*.cs] dotnet_diagnostic.SA1309.severity = none dotnet_diagnostic.SX1309.severity = warning ``` For teams not requiring file headers: ```ini [*.cs] dotnet_diagnostic.SA1633.severity = none dotnet_diagnostic.SA1634.severity = none dotnet_diagnostic.SA1635.severity = none dotnet_diagnostic.SA1636.severity = none dotnet_diagnostic.SA1637.severity = none dotnet_diagnostic.SA1638.severity = none dotnet_diagnostic.SA1640.severity = none dotnet_diagnostic.SA1641.severity = none ``` ## Rule Conflicts ### With SDK Analyzers Some StyleCop rules overlap with SDK analyzers: - IDE0003/IDE0009 vs SA1101: `this.` qualification - IDE0055 vs SA1000-SA1028: Spacing rules - IDE0161 vs SA1402: File-scoped namespaces Resolution: Disable the less-preferred analyzer in `.editorconfig`. ### With Roslynator - RCS1018 vs SA1400: Access modifiers - RCS1090 vs SA1101: `this.` prefix - Multiple formatting overlaps Resolution: Choose one analyzer pack as the authority for each rule category. ## Sources - [StyleCop Analyzers Rules](https://github.com/DotNetAnalyzers/StyleCopAnalyzers/tree/master/documentation) - [Rule Documentation Index](https://github.com/DotNetAnalyzers/StyleCopAnalyzers/blob/master/DOCUMENTATION.md) -
stylecop-analyzers.md 2.5 KB
# StyleCop.Analyzers ## Open/Free Status - open source - free to use ## Install ```bash dotnet add package StyleCop.Analyzers ``` ## Verify First Before adding the package, check whether the repo already references it: ```bash rg -n "StyleCop\\.Analyzers|stylecop\\.json" -g '*.csproj' -g 'stylecop.json' . ``` ## Ownership Model - keep severity and enable/disable policy in the repo-root `.editorconfig` - keep `stylecop.json` only for StyleCop behavior that `.editorconfig` does not express well - do not let `stylecop.json` become a second rule-severity system ## Common Usage - keep rule severity in the root `.editorconfig` - use `stylecop.json` for StyleCop-specific behavior where needed - run through normal build: ```bash dotnet build MySolution.sln -warnaserror ``` ## Root .editorconfig Example ```ini root = true [*.cs] dotnet_diagnostic.SA1200.severity = warning dotnet_diagnostic.SA1208.severity = warning dotnet_diagnostic.SA1516.severity = warning dotnet_diagnostic.SA1600.severity = none ``` ## stylecop.json Example ```json { "$schema": "https://raw.githubusercontent.com/DotNetAnalyzers/StyleCopAnalyzers/master/StyleCop.Analyzers/StyleCop.Analyzers/Settings/stylecop.schema.json", "settings": { "documentationRules": { "companyName": "Managed Code", "documentExposedElements": true, "documentInternalElements": false }, "orderingRules": { "usingDirectivesPlacement": "outsideNamespace", "blankLinesBetweenUsingGroups": "require" }, "layoutRules": { "newlineAtEndOfFile": "require" } } } ``` ## What stylecop.json Is Good For - documentation behavior - `using` placement - ordering behavior - file-header settings - indentation behavior that must match StyleCop expectations ## What Should Stay In .editorconfig - rule severity - whether a specific `SAxxxx` rule is warning, error, suggestion, or none - cross-analyzer ownership with SDK analyzers, Roslynator, or Meziantou ## CI Fit - use build warnings or errors as the gate - do not let `stylecop.json` replace `.editorconfig` as severity owner - keep `stylecop.json` in source control and schema-backed when possible ## When Not To Use - when the repo intentionally wants a lighter analyzer surface - when a bundled coding-standard package already supersedes StyleCop ## Sources - [StyleCopAnalyzers](https://github.com/DotNetAnalyzers/StyleCopAnalyzers) - [StyleCop Analyzers configuration](https://raw.githubusercontent.com/DotNetAnalyzers/StyleCopAnalyzers/master/documentation/Configuration.md)
-
-
SKILL.md 4.1 KB
--- name: dotnet-stylecop-analyzers version: "1.0.0" category: "Code Quality" description: "Use the open-source free `StyleCop.Analyzers` package for naming, layout, documentation, and style rules in .NET projects. Use when a repo wants stricter style conventions than the SDK analyzers alone provide." compatibility: "Requires a .NET SDK-based repository; respects the repo's `AGENTS.md` commands first." --- # StyleCop Analyzers ## Trigger On - the repo wants `StyleCop.Analyzers` - naming, layout, or documentation style needs stronger enforcement - the team needs `stylecop.json` guidance ## 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 - repos that intentionally rely only on SDK analyzers - repos where `StyleCop` overlaps too heavily with an existing style package and no consolidation is planned ## Inputs - the nearest `AGENTS.md` - current `.editorconfig` - any existing `stylecop.json` ## Quick Start 1. Read the nearest `AGENTS.md` and confirm scope and constraints. 2. Run this skill's `Workflow` through the `Ralph Loop` until outcomes are acceptable. 3. Return the `Required Result Format` with concrete artifacts and verification evidence. ## Workflow 1. Add `StyleCop.Analyzers` only if the repo wants its opinionated style rules. 2. Keep severity in the root `.editorconfig`. 3. Use `stylecop.json` only for StyleCop-specific behavioral options. 4. Prefer one checked-in `stylecop.json` per repo unless a project genuinely needs its own behavior. 5. Avoid rule duplication with SDK analyzers or other analyzer packs when possible. ## Bootstrap When Missing If `StyleCop.Analyzers` is not configured yet: 1. Detect current state: - `rg -n "StyleCop\\.Analyzers|stylecop\\.json" -g '*.csproj' -g 'stylecop.json' .` 2. Add package to the intended scope: - `dotnet add PROJECT.csproj package StyleCop.Analyzers` 3. Keep severity in root `.editorconfig` and use `stylecop.json` only for StyleCop-specific behavior. 4. Prevent overlap with existing analyzer packs by defining ownership. 5. Run `dotnet build SOLUTION_OR_PROJECT` and return `status: configured` or `status: improved`. 6. If the repo intentionally uses SDK analyzers only, return `status: not_applicable`. ## Deliver - explicit StyleCop package setup - repo-owned StyleCop rule configuration - clear split between root `.editorconfig` and `stylecop.json` ## Validate - StyleCop severity is versioned in repo config - `stylecop.json` is used only where it adds value ## Ralph Loop Use the Ralph Loop for every task, including docs, architecture, testing, and tooling work. 1. 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 2. Execute one planned step and produce a concrete delta. 3. Review the result and capture findings with actionable next fixes. 4. Apply fixes in small batches and rerun the relevant checks or review steps. 5. Update the plan after each iteration. 6. Repeat until outcomes are acceptable or only explicit exceptions remain. 7. If a dependency is missing, bootstrap it or return `status: not_applicable` with explicit reason and fallback path. ### Required Result Format - `status`: `complete` | `clean` | `improved` | `configured` | `not_applicable` | `blocked` - `plan`: concise plan and current iteration step - `actions_taken`: concrete changes made - `validation_skills`: final skills run, or skipped with reasons - `verification`: commands, checks, or review evidence summary - `remaining`: top unresolved items or `none` For setup-only requests with no execution, return `status: configured` and exact next commands. ## Load References - `references/stylecop-analyzers.md` - `references/rules.md` - `references/config.md` ## Example Requests - "Add `StyleCop.Analyzers` to this solution." - "Configure StyleCop without losing `.editorconfig` ownership."
Comments (0)
Sign in to join the conversation.
Reviews (0)
No reviews yet.
No comments yet.