review-loop

Review loop

This skill has one job: take a GitHub PR with open review threads and drive every thread, from every reviewer, to zero unresolved, iterating until the target is met, then report what it did in a fixed format. It does not QA the running application; that is autoqa's job. It does not decide whether the diff is safe beyond what reviewers raised; that is blast-radius's job. It does not merge, and it does not mint credentials.

Inputs

Auth precondition: the caller has authenticated gh before invoking this skill. The skill never mints, reads, or stores tokens. If gh auth status fails, stop and report it.

Iteration

Repeat until the target in step 9 is met. There is no iteration cap by default; a caller may pass --max-iterations to impose one. The loop still stops on timeout, a red gate it cannot fix, an auth failure, or a stall (see "Stop on stall"). Each iteration:

1. Sync with the base branch if the caller supplied a sync policy. Run the gate command when the head changed or no exact-head result exists. Reuse valid exact-head evidence. A red gate stops the iteration; fix the gate before touching review comments.
2. Fetch every open thread. See "Fetching everything". Do not filter to one reviewer.
3. Triage by content, not by author. For each thread decide: actionable (a code change is needed), informational (no change, reply explains why), or false positive (reply explains why). Record the decision. A reply that proves inherited behavior or base parity without a code push keeps prior exact-head evidence valid. Do not rerun gates or restart proof and description work.
4. Fix every actionable item in one pass. Read the file at the cited line, understand the comment in context, make the change.
5. If code changed, run the gate command again. Do not push a red gate.
6. If code changed, commit and push. Commit message names the iteration, for example Address review feedback (review-loop iteration 2).
7. Reply and resolve. See "Human threads" and "Bot threads". A reply goes on the thread that raised the point, not in a new top-level comment.
8. Re-request review once per push. A reply without a push does not require another request. See "Greptile specifics" and "Devin specifics". Wait for the results with a bounded poll.
9. Check the target. For review-clean or merge-ready, require zero unresolved threads across every reviewer and, when Greptile is installed, a 5/5 score from its latest summary. For open-for-review, require a non-draft PR and focused proof. Automated review may remain pending.