Agent skill
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 this agent skill to your Project
npx add-skill https://github.com/managedcode/dotnet-skills/tree/main/catalog/Tools/StyleCop-Analyzers/skills/dotnet-stylecop-analyzers
SKILL.md
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."
Recommended Agent Skills
Expand your agent's capabilities with these related and highly-rated skills.
dotnet-project-setup
Create or reorganize .NET solutions with clean project boundaries, repeatable SDK settings, and a maintainable baseline for libraries, apps, tests, CI, and local development.
csharp-scripts
Run single-file C# programs as scripts (file-based apps) for quick experimentation, prototyping, and concept testing. Use when the user wants to write and execute a small C# program without creating a full project.
dotnet-pinvoke
Correctly call native (C/C++) libraries from .NET using P/Invoke and LibraryImport. Covers function signatures, string marshalling, memory lifetime, SafeHandle, and cross-platform patterns. USE FOR: writing new P/Invoke or LibraryImport declarations, reviewing or debugging existing native interop code, wrapping a C or C++ library for use in .NET, diagnosing crashes, memory leaks, or corruption at the managed/native boundary. DO NOT USE FOR: COM interop, C++/CLI mixed-mode assemblies, or pure managed code with no native dependencies.
nuget-trusted-publishing
Set up NuGet trusted publishing (OIDC) on a GitHub Actions repo — replaces long-lived API keys with short-lived tokens. USE FOR: trusted publishing, NuGet OIDC, keyless NuGet publish, migrate from NuGet API key, NuGet/login, secure NuGet publishing. DO NOT USE FOR: publishing to private feeds or Azure Artifacts (OIDC is nuget.org only). INVOKES: shell (powershell or bash), edit, create, ask_user for guided repo setup.
dotnet-legacy-aspnet
Maintain classic ASP.NET applications on .NET Framework, including Web Forms, older MVC, and legacy hosting patterns, while planning realistic modernization boundaries.
dotnet-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.
Didn't find tool you were looking for?