Rabbit Round

Rabbit Round

Process one round of automated review feedback. Use /finish-pr when the user wants repeated monitoring until a pull request converges. Never request an automated review; handle the threads that arrive on their own.

1. Capture the Review State

Resolve the repository, PR, current head SHA, requester identity, draft state, and applicable comment-attribution rules. Fail visibly if the PR cannot be identified.

Pin every GitHub query and mutation to the resolved full owner/name repository and PR number; never rely on the checkout's implicit repository or branch. Require each fetched PR's repository identity, number, and headRefOid to match the captured identity. Before replying to or resolving feedback, refetch that exact PR and stop if its head changed; results from one head never authorize a mutation on another.

Fetch paginated review threads through GitHub GraphQL so unresolved state and thread replies are preserved. Fetch top-level issue comments separately. Record every participant and reply author in a thread, which comments apply to the current head, and which are stale. Classify participants from a fresh fetch. Record a receipt for every workflow reply and retain those receipts across resume or handoff. A review-thread reply receipt contains the returned review-comment node ID and exact content; a top-level reply receipt contains the returned issue-comment node ID and exact content. On later fetches, exclude a reply only when its surface, node ID, and content exactly match the corresponding receipt; never infer an exclusion from the requester account or an attribution footer. All remaining participants must be confirmed allowed bots; a human, mixed, or uncertain thread follows the human-thread rules.

Do not rely only on the REST review-comments list: it does not represent thread resolution or the complete conversation reliably.

2. Triage Every Actionable Bot Finding

Classify each unresolved bot review thread and each actionable top-level bot comment:

• Accept: correct and improves safety, behavior, tests, or maintainability.
• Accept with adjustment: the concern is valid but the proposed fix conflicts with repository structure or a stronger invariant.
• Already addressed: current code or a pushed commit demonstrably resolves it.
• Push back: incorrect, stale, speculative, or contrary to documented constraints.
• Defer: accepted, but landing in a named follow-up PR because the enclosing workflow's review budget is spent. Only with the follow-up PR's URL, and every defer in one run names the same PR. Never for a verified release-blocking defect (security, authorization, data loss, corruption): those are fixed on the current head.

Read the cited code and applicable instructions before deciding. Treat security, authorization, data loss, and compatibility claims as hypotheses to verify, not as votes to accept automatically. Never modify or resolve human review threads.

3. Implement Before Replying

Apply accepted changes, including tests when they cover a real failure mode. Run focused checks while iterating and the repository's canonical affected-change or CI-equivalent verification before publication when practical.

Commit and push the implementation before saying it is fixed. Push a new branch normally; use --force-with-lease only after intentionally rebasing a published branch. Capture the resulting head SHA. A newly published head cannot be clean in the same pass, even when GitHub has not registered checks or reviewers yet; classify it using the Section 5 precedence.