Reviewing Builds
Every completed build requires a human review before it ships. This is your quality gate — nothing moves forward without a real person saying it's good.
How It Works
When a build completes, it moves to “In Review” status. The reviewer (usually the project owner or lead) sees a summary of what was built, the effort report, any surprises, and a link to the code changes. They then submit one of three verdicts:
What to Look For
Scope match:Did the builder stay within the scope boundary? If they built extra features, that's scope creep — request changes to trim it back.
Acceptance criteria:Every task has a checklist of criteria. If any aren't met, request changes with a specific reference to the criterion.
Surprises:If the builder reported a surprise, read it carefully. Surprises often reveal assumptions that need to be updated in the project's strategy or documentation.
Effective Feedback
Good review feedback is specific and actionable. Instead of “this doesn't look right,” say “the task list should show priority badges next to each task name, but they're missing.” The builder should be able to address your feedback without guessing what you meant.
Remember: the builder is often an AI agent following a specification. If the output doesn't match what you wanted, the specification might need improvement — not just the code. Consider whether the feedback should go to the builder (request changes) or to the planner (update the spec for future tasks).