.NET Code Quality

This documentation was generated with the assistance of AI. Please report any inaccuracies.

Run this .NET/C# project or solution’s Roslyn analyzers — StyleCop.Analyzers for style/formatting and the CA rules from Microsoft.CodeAnalysis.NetAnalyzers for design/reliability/security bug detection — via a clean dotnet build with a SARIF diagnostic log, then read the generated report to summarize every issue found, grouped by tool. This is the .NET/C# equivalent of iru-java-code-quality (StyleCop.Analyzers ≈ Checkstyle, CA rules ≈ PMD
SpotBugs combined). It is a read-only reporting skill: it runs static analysis and reports results, it does not fix issues unless asked to as an explicit follow-up.

Purpose

iru-dotnet-code-quality gives a fast, focused lint pass without a separate per-tool CLI invocation — both StyleCop.Analyzers and the CA rules are Roslyn diagnostic analyzers, so both surface through the same build pipeline and the same SARIF log. It first confirms the analyzers are actually configured on the project (rather than reporting a misleadingly clean "zero issues" for a tool that isn’t wired up at all), runs a clean build with an ErrorLog diagnostic file, classifies every result by its ruleId prefix (SA/SX for StyleCop, CA for the analyzer rules, with CS/IDE diagnostics noted separately as out of scope), and can scope its summary to a single project/file/class even though the underlying build always analyzes the whole targeted solution/project.

Purpose group

.NET Development Tooling

Invocation

/iru-dotnet-code-quality
/iru-dotnet-code-quality <path-or-class-name>

Inputs

Argument Required Description Default

Argument	Required	Description	Default
`path-or-class-name`	No	Scopes the reported summary to matches in a specific project/file/class: results whose `artifactLocation.uri` ends in `/<Name>.cs` or matches the named project’s directory. The underlying `dotnet build` still analyzes the whole targeted solution/project regardless — Roslyn analyzers have no per-file CLI selector like Surefire’s `-Dtest`.	None — omitting it summarizes every issue across the whole solution/project.

path-or-class-name

Scopes the reported summary to matches in a specific project/file/class: results whose artifactLocation.uri ends in /<Name>.cs or matches the named project’s directory. The underlying dotnet build still analyzes the whole targeted solution/project regardless — Roslyn analyzers have no per-file CLI selector like Surefire’s -Dtest.

None — omitting it summarizes every issue across the whole solution/project.

Outputs

A plain-text summary in the conversation — never a written file.
Findings grouped by tool (StyleCop.Analyzers, then CA rules), then by file.
Per issue: file:line, rule ID, severity (error/warning/note), and the message.
A total issue count per tool at the top and an overall total; a tool with zero issues is called out explicitly as clean — or, if it isn’t actually configured on the project, as not-configured rather than a false clean pass.
Any CS (compiler) or IDE (.editorconfig-driven) diagnostics found are mentioned as a separate, out-of-scope bucket rather than folded into either tool’s count.
No source, project file, .editorconfig, or stylecop.json is ever modified.

Execution flow

flowchart TD A["Start /dotnet-code-quality\n(optional path-or-class-name)"] --> B["Check StyleCop.Analyzers and CA rules\nare actually configured on the project"] B --> C["dotnet clean; dotnet build\nwith -p:ErrorLog=...sarif,version=2"] C --> D{Build produced\na SARIF log?} D -- no, genuine compile error --> E["Report failure, stop\n(reports not freshly regenerated)"] D -- yes --> F["Read the generated .sarif file"] F --> G["Classify each result by ruleId prefix:\nSA/SX, CA, CS, IDE"] G --> H{Scope argument given?} H -- yes --> I["Filter results to the\nmatching file/project/class"] H -- no --> J["Keep full solution-wide results"] I --> K J --> K["Group findings by tool, then by file"] K --> L["Report file:line, rule, severity, message,\nplus totals per tool and overall"]

Dependencies

Invokes

None — iru-dotnet-code-quality is a leaf skill; it only runs dotnet commands and reads the generated SARIF report, it does not call any other skill in this catalog.

Invoked by

Code — Steps 3 and 7, once per run (not per task group), via the iru-gate-runner agent, to capture and later re-check a project-wide quality baseline for the dotnet language/framework key.
.NET Code One Task Group — Steps 1 and 3, once per task group’s bucket, via the iru-gate-runner agent, to capture a pre-change baseline covering every type the bucket touches and later diff the post-change result against it.

Related agents

iru-gate-runner — both callers above always invoke this skill from inside a iru-gate-runner sub-agent they spawn, not inline.

Source

SKILL.md on GitHub — the file this page was generated from.