# Review Queue > Fan out isolated, one-per-PR reviews across your queue (own context + worktree per PR, no cross-pollution), then synthesize one report. Pulls the queue from a review inbox (zen) or gh; posts nothing without per-PR authorization. - Skill: `jamestexas/review-queue` (Agent Skill) - Install (CLI): `npx skillmds@latest add jamestexas/review-queue` - Raw SKILL.md: https://api.skillmd.com/api/skills/jamestexas/review-queue/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Docs & Writing - Author: jamestexas (https://skillmd.com/u/jamestexas) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/jamestexas/review-queue --- # Review Queue — isolated per-PR reviews, fanned out and synthesized The problem this solves: reviewing N peer PRs in one long session pollutes context — findings, file reads, and design intent from PR A bleed into PR B. This skill keeps each review in its **own sub-agent + own git worktree**, then consolidates. One command, N clean reviews, one report. **Model:** the orchestrator (you, the main session) builds the worklist, dispatches one `pr-reviewer` sub-agent per PR, and synthesizes. The sub-agent carries the discipline (pr-review-kit) and `isolation: worktree`; the orchestrator never reviews a PR itself (that would re-pollute the main context). ## Arguments A list of PR numbers/URLs to review (e.g. `42088 42090 39311`, or full `chainguard-dev/mono#42090` refs). If empty, the skill builds the queue from your review inbox (Phase 0). --- ## Phase 0 — Build the worklist + catch up 1. **Get the queue** (first source that's available): - **zen** (if the `zen` MCP is connected): call `zen_inbox` — PRs awaiting *you* (configured authors + explicit review requests). This is the intended source. - **gh** fallback: `gh search prs --review-requested=@me --state=open --json number,title,repository` (and/or the repos you care about). - **args**: if the user passed PR refs, use those verbatim — skip discovery. 2. **Catch up via an observational memory layer** (optional — only if your harness provides one, e.g. a memory/timeline MCP) — for each PR you're about to review, a quick timeline / text search to surface *what changed and who reviewed since you last looked* (especially if it's a re-review). This is the "stay current" layer — query it, don't carry it. Skip silently if no such source is connected. 3. **Confirm the list with the user** before dispatching — show `repo#number — title` for each, note any that are drafts or already-approved, and let them prune. Don't fan out a dozen agents on an unconfirmed list. --- ## Phase 1 — Fan out (one isolated reviewer per PR) Dispatch one **`pr-reviewer`** sub-agent per confirmed PR, **in parallel** (independent work, no shared state). Each `pr-reviewer` already declares `isolation: worktree` + read-only tools, so it gets its own repo copy and clean context. In each dispatch prompt, give the agent exactly what it needs (it can't ask you): - `OWNER`, `REPO`, `N` (PR number) - the canonical remote name for fetching (`upstream` on a fork checkout, else `origin`) - intent: **review-only — return a structured summary, post nothing** - any design-doc pointer you have (path/URL), so it doesn't have to hunt blind Label each agent by PR (e.g. `review:mono#42090`) so progress is legible. Sub-agents can't spawn sub-agents — that's fine; the worker is flat by design. > Scale note: ~5 PRs fan out cleanly as parallel sub-agents. If you're ever past ~10–15, or you want the reviewers to adversarially cross-check each other before reporting, that's the **Workflow** tool's territory (codified orchestration, dozens of agents) — switch to it rather than hand-dispatching. --- ## Phase 2 — Synthesize Collect each sub-agent's structured summary (verdict + falsifiable matrix + blockers/nits/questions). Then produce **one** consolidated report: - **Per-PR line:** `repo#N — VERDICT — one-line why` (sortable: BLOCKED/CHANGES first, SHIP last). - **Cross-PR themes:** anything that recurs (same nit across PRs, a shared dependency two PRs both touch, a design question that spans them). This is the value the orchestrator adds over reading N separate reports. - **What needs *you*:** the short list of PRs where a human decision is required (a design call, an approve, a "reply to reviewer"). Verify before relaying: the sub-agents are competent but not infallible (misidentified targets, stale framing, phantom citations). For any **blocker** a sub-agent reports, spot-check its evidence command against the actual code before you present it as fact. --- ## Phase 3 — Post (only on explicit, per-PR authorization) **Default posture: post nothing.** The report is local until the user says, per PR, "post the review on #N" or "approve #N." Posting is the one side-effect that's visible to others; never batch-post or infer authorization. When authorized, follow pr-review-kit Phase 8 (body-only review, inline threads, or atomic batch) and verify it landed. --- ## Hygiene - The `pr-reviewer` worktrees auto-clean when the agent makes no changes — and a review makes none — so they shouldn't accumulate. Still, `git worktree list` periodically and prune anything stale. - This skill orchestrates; the **pr-reviewer** agent and **pr-review-kit** skill carry the per-PR discipline. Keep the division: orchestrator builds the list + synthesizes; worker reviews one PR in isolation.