| name | review-batch-orchestrator |
| description | Use when multiple tickets are expected to converge into one shared human-review wave, followed by patch and re-review loops that should stay synchronized instead of ad hoc. |
Review Batch Orchestrator
Use this skill when the question is:
- how do we review multiple tickets in one wave
- when do grouped review and grouped patch blocks happen
- how do we keep patch and re-review from becoming random ticket-by-ticket churn
This skill is the review-wave planner for a multi-ticket day.
If the correct review posture is not a grouped wave but a strict one-by-one signoff conveyor belt,
route to ../sequential-ticket-review-queue/SKILL.md
instead.
Inputs to gather first
- current execution waves
- tickets expected to reach review today
- ticket owners
- human-review availability
- known serialized review surfaces
- patch expectations or likely risk areas
Start by reading:
../ticket-human-review-runtime/SKILL.md../ticket-to-human-review/SKILL.md../parallel-lane-orchestrator/SKILL.md../references/git-merge-close-gate.md
Goal
Produce one streamlined review wave:
- grouped review when multiple tickets are ready together
- explicit patch wave when findings land
- explicit re-review wave when patches settle
- explicit post-signoff merge gate per verified ticket
For DB-proof campaigns, grouped machine review is the default, but human review should stay
isolated to only the tickets whose classified surface genuinely needs a human verdict.
Workflow
1. Build the review set
Collect tickets that are likely to hit review in the same day window.
Rules:
- do not group tickets that depend on unresolved upstream work
- do not mix unrelated review contexts if that would confuse the human reviewer
- for DB-proof campaigns, keep receipt-truth corrections grouped with their matching proof wave so
the trust story cannot drift ahead of the substrate
2. Decide grouped versus isolated review
Use grouped review when:
- several tickets belong to the same execution wave
- the same human can review them in one pass
- the risk is coherence and convergence, not just single-ticket correctness
Use grouped machine review plus isolated human review when:
- many tickets share the same proof substrate or receipt repair wave
- only a subset actually exposes a human runtime surface
- the human should not babysit operator-only or API-only tickets
Use isolated review when:
- one ticket is much riskier
- one ticket owns a separate runtime surface
- one ticket is not ready with the rest of the wave
Use sequential signoff queue when:
- the human wants to finish one ticket fully before touching the next
- each ticket has its own surviving worktree and should be validated there
- merge-to-main and the
issue_tracker terminal Done state should happen ticket by ticket instead of after one shared wave
- the main risk is operator focus and honest closure, not cross-ticket coherence
3. Plan the patch loop
For grouped review findings:
- route each finding back to the owning ticket lane
- batch patch time into one explicit patch wave
- avoid scattering micro-patches throughout the rest of the day
- if a DB-backed proof lane fails, patch the substrate or receipt truth once, then fan the rerun
back across the affected ticket set instead of treating each ticket as a bespoke failure
4. Plan re-review
After the patch wave:
- schedule a grouped re-review if multiple tickets changed
- schedule isolated re-review only when one ticket remains unstable
- after a ticket clears human review, keep its merge-to-main and root-main proof gate explicit
- do not treat a grouped human wave as permission to bulk-close tickets before main is green
Close rule
This skill is complete only when:
- the review set is explicit
- grouped versus isolated review is justified
- patch follow-through is scheduled intentionally
- the re-review path is explicit rather than implied
- the post-signoff merge gate is explicit instead of being hand-waved into
Done
