Iterative Review Loop

Spawn a fresh reviewer subagent, triage feedback by severity, fix relevant issues with individual commits, and loop until the code is clean. Pause every 5 rounds to confirm continuation.

oh-my-opencode users: See iterative-review-omo for a version with named agent routing (oracle reviewer + hephaestus implementer).

Trigger

Use this skill when the user says any of:

• "review my code", "iterative review", "review loop"
• "review until clean", "loop review"
• /iterative-review

Arguments

[context] (optional) — brief description of what was just built. If omitted, context is inferred automatically.

Step 0 — Gather Context

Determine the feature description using this priority order:

1. Explicit argument — if the user passed context, use it verbatim. Skip to Step 1.

2. Session context — if you have been actively working on this feature in the current conversation (you implemented, modified, or discussed specific files/logic in this session), you already have the context. Summarize what was built in 2-3 sentences from memory. Skip the git commands. Skip to Step 1.

3. Git fallback — only if neither of the above applies (cold start, someone else's code, long unrelated session):

git diff HEAD~1..HEAD
git log --oneline -5

Synthesize a 2-3 sentence feature description from the diff and log.

Step 1 — Spawn a Fresh Reviewer

Spawn a fresh reviewer subagent (not yourself — a clean context, no prior conversation history) with this exact framing:

You are a senior code reviewer. Review the following diff and provide structured feedback.

What was built: {feature_description}

Diff:

{git_diff}

Return feedback in this exact format:

Critical (must fix before merge)

• [issue]: [specific location] — [why it matters]

Important (should fix)

• [issue]: [specific location] — [why it matters]

Minor (nice to have)

• [issue]: [specific location] — [suggestion]

Praise (what's good)

• [what works well]

If you have zero Critical and zero Important issues, end your response with exactly: LGTM ✅

Why a fresh subagent? Reviewers accumulate bias after seeing your fixes. A fresh context each round gives honest, independent feedback.

Step 2 — Triage Feedback

Critical / Important → Fix it (unless you have a strong technical reason not to):

• Agree: fix immediately → commit fix(review): <short description> [round N]
• Disagree: state technical reasoning in 1-2 sentences, do NOT fix → log as Skipped: {reason}
• Unclear: ask the user before proceeding

Minor → Fix if trivial (< 5 lines), log otherwise:

• Fixed: commit fix(review): <short description> [round N] [minor]
• Skipped: log as Deferred minor: {description}

Irrelevant / Wrong:

• Log as Skipped (not applicable): {reason}

After each round, print a triage summary:

Round N summary:
  ✅ Fixed (Critical):    X issues
  ✅ Fixed (Important):   Y issues
  ✅ Fixed (Minor):       Z issues
  ⏭️  Skipped (rejected):  A issues — [brief reasons]
  ⏭️  Deferred (minor):    B issues

Step 3 — Check Exit Condition

Exit if the reviewer's response contains LGTM ✅ OR zero Critical/Important issues remain after triage.

✅ Iterative review complete.
   Rounds:                N
   Total fixes committed: M
   Deferred minors:       K (logged above)

Stop. Do not spawn another round.

Step 4 — Loop or Checkpoint

Round < 5 and not clean: go back to Step 1 with a fresh reviewer spawn.

Round is a multiple of 5 and not clean: pause and ask:

⏸️  5 rounds completed (N total).
   Issues fixed this batch: X
   Reviewer still has Critical/Important comments.

   Continue another 5 rounds? (y/n)

• Yes: continue from Step 1, tracking cumulative totals
• No: stop, show full session summary including all deferred and skipped items

Commit Convention

fix(review): <issue description> [round N]
fix(review): <issue description> [round N] [minor]

Examples:

• fix(review): add null check for user input [round 1]
• fix(review): extract magic number to constant [round 2] [minor]

Anti-Patterns

NEVER:

• Bundle multiple issues into one commit — one commit per issue
• Accept reviewer feedback blindly — verify against the actual codebase first
• Spawn the reviewer without the real diff — it cannot review what it cannot see
• Continue past a 5-round checkpoint without explicit user confirmation

NEVER stop early because:

• "The code looks fine to me" — if the reviewer has Critical/Important items, address or explicitly reject with reasoning
• "Only minor issues left" — minors are fine to defer; Critical/Important are not