PAPI
InstallGuideHandbookToolsChangelogDiscord

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:

Accept
The build meets the specification. The task moves to Done and becomes part of the next release. This is the happy path — most builds should be accepted.
Request Changes
The build is mostly right but needs adjustments. The task goes back to In Progress with your specific feedback. The builder addresses your notes and submits again. This is for bugs, scope misses, or quality issues — not for new features.
Reject
The build is fundamentally wrong and needs to start over. Use sparingly — request changes is almost always better than reject. Reject is for cases where the entire approach was wrong.

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).

Previous
Cycle Reports
Next
Team Roles