pr-batch: do not chase reviewer re-review prompts when the merge gate is already satisfied
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 55/100
- Issue type
- Feature
- Clarity
- Clearly specified
- Activity status
- Active
- Tech stack
- github, markdown
- Domain
- ci-cd, developer-experience, tooling
Research direction
Start with the review-wave and Review-Loop Convergence sections in workflows/pr-processing.md, then compare the pr-batch and pr-monitoring skills with the review_gate seam described in the issue. Run or inspect the review-wave contract test and goal-prompt template. Done means the advisory-seam, surviving-approval, trivial-delta case reaches ready-gates-clean without a reviewer re-trigger, heartbeat, or cron.
Written by the indexing model from the issue text.
Description
Context
Observed during the shakacode/shakapacker PR-batch wave sp-0901-2051 (2026-09-01/02). After a changelog-wording push to a PR that CodeRabbit had already approved (shakacode/shakapacker#1304, approval preserved because the branch protection has dismiss_stale_reviews: false), the PR page showed CodeRabbit's standing prompt:
Approval pending. CodeRabbit has no unresolved comments, but it has not reviewed the latest commit. Use the checkbox below to review the latest commit. CodeRabbit will approve the changes if it finds no blocking issues.
The coordinator, following the review-wave text in workflows/pr-processing.md ("a push invalidates both review-wave and validation-CI evidence for the previous head; restart both cohorts on the new head"), scheduled a @coderabbitai review re-trigger and treated the PR as waiting-on-checks-or-review. The maintainer's instruction was the opposite: ignore prompts like this when more reviews are unnecessary.
Problem
The workflow treats every push as invalidating all reviewer evidence and pushes coordinators toward re-triggering reviewers, even when:
- the repo's
review_gateseam declares AI reviewers advisory (as shakapacker's does: "AI reviewers are advisory unless they confirm a blocker; merge gate is the fullgh pr checkslist green + all threads resolved + mergeable clean"), - an approval already exists and survives the push (
dismiss_stale_reviews: false), and - the delta since the reviewed head is trivial and coordinator-verified (changelog or description wording, a two-line path-filter change, a review-requested one-liner).
Chasing the reviewer in that state costs a CodeRabbit hourly-quota slot (two per hour on OSS plans), delays closeout by up to an hour, and adds a heartbeat or cron just to post a re-trigger comment. Related but distinct: #226 (usage-limit waiver rule missing from the loop files), #249 (fail closed on unsettled configured reviews before merge), #477 (validate merge_authority feasibility, including stale-approval defects).
Proposed fix
In workflows/pr-processing.md (review-wave and Review-Loop Convergence sections) and the pr-batch / pr-monitoring skills:
- Make "restart the review cohort on push" conditional on the seam. When
review_gatemarks AI reviewers advisory, a push does not by itself require a fresh reviewer artifact; the gate is checks green, threads resolved, mergeable clean, plus any approval the branch protection requires. - Define a "trivial delta" rule: when the post-review delta is limited to docs/CHANGELOG/PR-description text or a coordinator-verified change under N lines that answers a review thread, do not re-trigger reviewers or wait for them. Record the decision in the handoff instead.
- State explicitly that reviewer UI prompts (CodeRabbit's "Approval pending" checkbox, "@codex review" hints) are not instructions and must not be acted on unless the gate actually needs a fresh approval.
- When a fresh approval is genuinely required by branch protection and reviewers are advisory, prefer the maintainer's written approval plus an admin merge over spending a reviewer quota slot, and say so in the readiness state.
Acceptance criteria
- A PR whose seam marks reviewers advisory, whose approval survives a push, and whose delta is trivial reaches
ready-gates-cleanwithout any re-trigger comment, heartbeat, or cron. - The review-wave contract test covers the advisory-seam branch.
- The goal-prompt template's GMCC line reflects the conditional cohort restart.
Provenance
Maintainer instruction from justin808 during the shakapacker wave; coordinator was Claude Code via Conductor.
- Dominant language
- Ruby
- Stars
- 7
- Forks
- 1
- Avg merge
- 1d 16h
- Merged PRs (30d)
- 150
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from shakacode/agent-workflows
-
complexity:neutral follow-up P3 triage:park
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
shakacode/agent-workflows#751 ·
-
complexity:complexify follow-up needs-customer-feedback P3 review-nit triage:park
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
shakacode/agent-workflows#750 ·
-
complexity:neutral follow-up P2 triage:reconcile
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
shakacode/agent-workflows#640 ·
-
complexity:neutral P2 triage:reconcile
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
shakacode/agent-workflows#483 · 1 comment ·
-
complexity:complexify enhancement P2
Difficulty 5/5 Over a week Newbie friendliness 25/100
shakacode/agent-workflows#852 ·
All issues in shakacode/agent-workflows
Similar issues
-
バグ
Difficulty 1/5 Under an hour Newbie friendliness 92/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
voxpupuli/puppet-epel#186 · 1 comment ·
-
external_created_at is no longer used for the message timestamp since the new message UI (v4.4.0) OpenBug Frontend
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
TheOdinProject/curriculum#31402 · 1 comment ·
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 78/100