ralphctl-iterative-reviewlisted

# Iterative Review > Concept > > from [Martin Fowler — "Iterative Review"](https://martinfowler.com/articles/structured-prompt-driven/iterative-review.html). > Adapted for ralphctl's three phases. One-shot generation looks fast and is slow. The cheap review you skipped at iteration N becomes the expensive unwind at iteration N+5, when a regression that lived undetected through five steps surfaces only at the post-task gate. Catching a problem at the seam between two changes is cheap; catching it at the end of a 200-line diff is not. The harness's check gate, the evaluator, and the review prompts are this loop in deployed form — but the same posture also belongs **inside** each phase's work. ## When this applies - **Refine** — re-read the drafted criteria once against the ticket before sending. Strike duplicates; tighten "should" / "ideally" into checkable predicates. Cheap to do here, expensive once planning splits tasks against the unclear version. - **Plan** — re-read the generated task list against the requirements. Are the tasks independently shippable? Do dependencies match the actual data flow? Reorder, merge, or drop before importing. - **Execute** — run the project's check gate (lint, typecheck, tests) after each meaningful change, not after the whole diff. Re-read your own diff once before signalling `<task-complete>`. You are the cheapest reviewer the change ever gets. ## What to do 1. **Run the cheapest check first, often.** Lint, typecheck, narrow