Review Loop

Usage

/core-skills:review-loop <artifact> [goal or review criteria]

Goal

Iteratively improve $ARGUMENTS through review cycles until convergence.

The Rule That Matters Most

Every round must introduce information the author didn't have. A different model reviewing in fresh context. Test/lint/backtest output. New search results. If the only input is the author re-reading its own work, the round is net negative — models change correct answers to incorrect ones more often than they fix errors. If you cannot introduce external signal, stop iterating.

Protocol

Step 1 — Anchor

Define the Problem Anchor: what is this artifact supposed to achieve? State as a concrete success criterion. Carry it verbatim through every round. Feedback that would change the goal is drift — reject it explicitly.

Step 2 — Review

Re-state the Problem Anchor before reviewing.

Get review from an external source. Options, in order of preference:

1. Different model — Codex, Gemini, or a context-separated background subagent (fresh context, not same session)
2. Tool execution — run tests, linters, type checkers, backtests
3. Evidence retrieval — search for sources, check claims

The reviewer receives the artifact, the Problem Anchor, and an adversarial mandate: "Find what's wrong. Be specific — cite locations and explain why it matters. Do not confirm quality."

Step 3 — Address with Pushback

Read the review. For each finding:

• Accept — incorporate the fix
• Reject: drift — finding would change the goal, not improve the artifact. Cite the Problem Anchor.
• Reject: evidence — finding is based on a misread. Cite the specific code/data/reasoning that makes it wrong.
• Reject: disproportionate — fix adds complexity that outweighs the issue.

"I disagree" without evidence is not valid pushback. When you produced the artifact being reviewed, evaluate findings against the Problem Anchor and pushback criteria — not your prior assessment of your own work.

Record each finding and its disposition in a markdown table:

Outcome is accepted or rejected with a one-line reason. For rejections: factually wrong (evidence), would drift from the Problem Anchor (drift), or costs more than it's worth (disproportionate). When a finding is partially accepted, split into two rows. When valid but already addressed, record as accepted: already present, no change needed.

Include this table in the delivered artifact or present it with the delivery summary.

Step 4 — Convergence Check

Stop when ALL three hold:

1. No new substantive feedback — reviewer found nothing new (cosmetic or style-only feedback doesn't count)
2. No drift from the Problem Anchor
3. Hard cap not exceeded — default 5 rounds (user can override)

If converged → deliver. If not → return to Step 2. Use a different review lens each round to avoid re-running the same check.

Early exit: If Round 1 review finds no substantive issues, stop. Don't iterate for the sake of iterating.

Step 5 — Deliver

Present the final artifact with:

• Rounds completed and what changed in each
• Any rejected feedback worth noting (so the user can override)
• Unresolved disagreements

Anti-Patterns

Self-review without external signal. The single strongest finding in the literature. Self-correction without external signal degrades quality across all benchmarks. Every round MUST introduce new information.

Unlimited rounds. Meaningful improvement concentrates in rounds 1-2. After round 3, models entrench and semantic compression erodes nuance. Respect the hard cap.

Sycophantic review. Agents default to agreement — sycophancy collapses loops into premature false convergence. Every reviewer gets an explicit adversarial mandate. Convergence from a polite reviewer is not real convergence.

Score-only convergence. Scores aren't calibrated across rounds or reviewers. Use the conjunctive check: no-new-feedback AND no-drift AND hard-cap. All three, not any one.

Fallback

Try: primary model → secondary model → context-separated background subagent (fresh context). Never fail because an external model is down.