dotnet-review

Delegating to dotnet-code-review

This plugin ships one review subagent, dotnet-code-review. Each invocation reviews all quality aspects at once — correctness, naming, styling, best practices, performance, concurrency, security, testing, XML documentation, cleanup/duplication — over one stated scope. It starts with no prior context of the project: it reads code and the shared standards under the plugin's standards/ fresh, like a senior developer seeing the codebase for the first time, and reports findings without editing anything. Route review requests to it instead of reviewing inline yourself — it reads the actual standards files, which you have not loaded.

Step 0 — check workspace readiness before launching

Call workspace_status yourself, before spawning anything. Each instance starts cold and cannot fix a broken workspace; launching several against one is a parallel waste, not a parallel review.

• workspace: degraded, or projects under failed: — semantic results may be silently wrong, not merely thin. A review run against it reports findings it cannot stand behind. Fix the build, reload_workspace, then spawn.
• Still loading, or index-only — get_references, get_call_hierarchy, get_type_hierarchy and get_semantic_diff return nothing rather than nothing-found, and the classic failure is an instance reporting live code as dead. Wait for it.
• After a git checkout/pull/rebase, or a new or deleted .cs file — reload_workspace(scope: "all") first, or every instance's line numbers are wrong.
• Take pluginRoot from the same response and state it in each instance's brief, so no instance has to rediscover where the standards live.

State the readiness verdict in the merged report. A review run on a degraded workspace is reported as such, never as clean.

It loads standards selectively. The routing table is <pluginRoot>/standards/index.md, shared with dotnet-write. Six files are read every time (naming, styling, best-practices, xml-documentation, antipatterns, security); the other seven are read only when the retrieved code matches their "When" condition in that table. This keeps each instance's baseline down — the cost is paid once per parallel instance, so it dominates a multi-instance run — and every report ends with a Standards: line naming what was loaded and what was not. Treat an untriggered aspect as not assessed, not clean.