code-review-loop

Code Review Loop

Capability

Run the canonical working loop from the loops/autoresearch research: a read-only critic scores a diff and raises evidence-backed findings, a read-write fixer addresses ONLY those findings, then the critic re-audits. Repeat until two consecutive clean rounds or a cap. The separation is the whole point — the thing that judges the code cannot edit the code, so it cannot pass the review by loosening it (the Sprint 6a read-only principle, applied to review).

Use Cases

• Reviewing a pull request to a converged, clean state.
• Hardening one changed file or surface before merge.
• Turning a pile of review comments into addressed-and-re-verified findings.
• Any "iterate until clean" task where "clean" is a checkable signal, not a vibe.

When NOT to use this skill

• No checkable signal for "done". If "good" is subjective taste with no test, gate, or rubric, a loop just burns tokens. Do a single review pass instead.
• Green-field authoring. This loop reviews and fixes an existing diff; it does not design features from scratch.
• Structural rewrites. The fixer addresses raised findings on a named surface. A loop will not invent an architecture change that needs a step backwards first.
• Unbounded scope. If every round surfaces a brand-new area, the surface is too big. Narrow it first.

The two roles (never the same agent on the same turn)

Role	Tools	Model	Job
Critic	Read-only (Read, Grep, Bash for running checks — NO Edit/Write)	A different model to the fixer	Score the diff, raise findings with file:line + evidence. Never edits code.
Fixer	Read-write (Edit/Write on the named surface only)	The session default	Address ONLY the raised findings. Never edits the gate, the test, or the critic's rubric.

Run the critic on a different model to the fixer. Read-only separates the incentives; a different model separates the blind spots. A critic sharing the generator's weights inherits the same assumptions and tends to return agreement rather than verification, so a same-model critic scoring its own family's work is closer to a consistency check than a review. Switch with /model between roles, set CLAUDE_CODE_SUBAGENT_MODEL, or pass opts.model if you are driving the loop from a script. If only one model is available the loop still works and is still worth running: note in the log that critic and fixer shared weights, and treat a clean round as weaker evidence.