.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.

It is also Windows-desktop aware and safe for multi-project solutions. A single shared ErrorLog path is overwritten by parallel project builds (verified: the file was not even valid JSON), so for a solution it builds once to put dependencies in place and then re-compiles each project on its own with its own SARIF log (or reads the per-project obj/<Project>.sarif logs when Directory.Build.props already writes them, as the iru-setup-windows-app scaffold does). On a non-Windows host it passes -p:EnableWindowsTargeting=true so WPF and Windows Forms projects are analyzed too, and reports a WinUI 3 project (whose XAML compiler only runs on Windows) as "not analyzed (needs Windows)" rather than failing or implying it is clean. Results carrying a non-empty suppressions array are counted separately, not as issues; the MSTEST, WPF/WFO/WFAC and MVVMTK rule prefixes are classified as their own groups. A closing "Known quirks" section records what was verified on macOS with the .NET 10 SDK.

Purpose group

.NET Development Tooling

Plugin

Shipped by the iru-dotnet plugin of the ai-catalog marketplace (install with /plugin install iru-dotnet@ai-catalog; see Plugins).

Invocation

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

Inputs

Argument Required Description Default

Argument	Required	Description	Default
`baseline`	No	A `baseline: <previous issue list>` line (passed by the `*-code-one-task-group` skills): only issues not present in the baseline are reported — compared by rule id, file and, when unmoved, line — plus a one-line count of baseline issues that disappeared.	None — every issue is reported.
`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.

baseline

A baseline: <previous issue list> line (passed by the *-code-one-task-group skills): only issues not present in the baseline are reported — compared by rule id, file and, when unmoved, line — plus a one-line count of baseline issues that disappeared.

None — every issue is reported.

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.
With a baseline:, only the newly introduced issues plus the count of resolved ones; suppressed results and projects not analyzed on this host (a WinUI project off Windows) are named separately — "not analyzed", never "no issues".
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 --> B2["Windows desktop projects?\nnote host; add EnableWindowsTargeting\noff Windows; skip WinUI projects"] B2 --> C["dotnet clean; dotnet build, one SARIF log\nper project (or the repo's own\nobj/*.sarif logs)"] 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, MSTEST, WPF/WFO, MVVMTK, CS, IDE;\nset aside suppressed results"] 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 --> K2{baseline: given?} K2 -- yes --> K3["Keep only issues absent from\nthe baseline; count resolved ones"] K2 -- no --> L K3 --> 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 — Step 3 and 7, quality baseline and comparison for .NET plans (and the windows key, which also resolves here), via the iru-gate-runner agent.
.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.
Windows Code One Task Group — the same baseline-and-diff role for Windows desktop app buckets, via iru-gate-runner.

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.