Keep revisions from multiplying the queue

A review request should create one bounded next pass. Collect related comments, distinguish blockers from optional improvements, and preserve the original acceptance criteria. If the review discovers separate work, open a new task rather than attaching it to the current change unless release safety depends on it.

Ask the agent to explain how each blocking comment was addressed and which tests changed. The reviewer should compare the new diff with the previously reviewed version, not restart from the repository base each time. Force-pushing can be acceptable in a controlled workflow, but retain enough history or review tooling to see what changed between rounds.

Set a revision limit as a prompt for reassessment rather than an automatic rejection. Repeated rounds often indicate that the task is ambiguous, the design lacks an owner, or the agent is operating beyond the useful context window. Stop, rewrite the task and start a clean implementation when that costs less than untangling the branch.

Watch for patch accretion. An agent may keep earlier work and add conditionals around each comment until tests pass. The result can satisfy every local request while becoming difficult to reason about. After substantial revision, review the complete final design and ask whether any superseded path remains.

Resolve merge conflicts as new work. A mechanical conflict resolution can change behaviour when both branches altered the same contract. Rerun affected tests and have a reviewer inspect the combined result. An agent that authored one side should not silently choose the meaning of the other.

Close rejected branches and record the reason. The task board should not leave them appearing active, and later agents should not rediscover them as viable prior work. Keep any useful diagnosis in the issue, then remove disposable worktrees and branches according to repository policy.