Code Review & Auto-Fix

Review code in any language plus IaC/config, then fix what is safe and flag what is not. The value of this skill is the discipline of the fix-vs-flag gate, not the size of the catalog. Lead with the workflow; pull deep taxonomies from references/ only when a finding needs them.

When to activate

Any request to review, audit, critique, clean up, simplify, harden, or fix code, config, or infrastructure — PR/diff review, "look over my changes," security review, IaC audit, refactor. If the user just says "review" and the context is more than a style pass, this applies.

In a spec-driven flow (PRD → issues → PR → review → merge), this runs after the PR is built and before the merge. Its job is to emit a clear verdict — not to merge programmatically. Per the Development Workflow in ~/.claude/CLAUDE.md, the verdict gates the merge: AFK issues may auto-merge only when CI is green and all findings are resolved; HITL issues always stop at ready-for-review for a human merge.

The review loop

1. Scope the change. Identify what to review and get the actual diff: uncommitted work git diff (add --staged for the index), a branch git diff main...HEAD, or a PR gh pr diff <n> (with gh pr view <n> for intent). Specific files or a directory are also valid scopes. If the range is ambiguous, ask which before reviewing. Read enough surrounding context (the whole function/file, callers) to judge each finding; do not expand the fix scope beyond what was asked.
2. Detect tests. Check for a test suite and how to run it (just, pytest, go test, npm test, etc.). Whether tests exist changes how aggressively you may auto-fix (see the gate).
3. Scan across dimensions — via subagent fan-out (see below). Dispatch parallel read-only reviewer subagents, one per dimension: code smells, refactoring/simplification opportunities, principle violations, security issues, performance/correctness/concurrency bugs, and IaC/config misconfigurations. Each routes to its matching reference file for the catalog and canonical fix. On a large diff, triage: cover blocking/security and major findings first, cap the nits, and explicitly state what you did not get to — never truncate silently.
4. Classify each finding on two axes: severity (blocking / major / minor / nit) and fix-safety (auto-fix vs. flag-only). The cross of these two drives what you do.
5. Apply safe fixes as small, atomic, one-logical-change diffs. After each fix, run the narrowest relevant tests if they exist; run the full suite once at the end. Flag everything judgment-dependent or behavior-changing — do not silently apply it.
6. Report in Conventional Comments form, grouped by severity, each finding marked auto-fixed or flag-only with a one-line why.