/autopilot-batch

name: autopilot-batch
description: Fan out a batch of autopilot-queued issues to parallel background worktree subagents — each runs /autopilot at the build model from its 'model:' label — with a gating review at Opus 5 or above and never below the build (Opus reviews Sonnet and Opus builds, Fable reviews Fable builds).
disable-model-invocation: true
argument-hint: "[--merge <issue#,…>]"

Autopilot Batch

Run the vetted `autopilot-queued` queue as a parallel batch: one background `isolation: worktree` subagent per issue, each running `/autopilot <n>` end-to-end at the build model its `model:` label calls for, with a gating `review` at **Opus 5 or above and never below the build** (Opus for Sonnet- and Opus-built PRs, Fable for Fable-built PRs). This is the **run** half of the triage → run split; `/autopilot-triage` is the **vet** half that fills the queue.

Use this when you have a queue of independent, well-scoped issues and want them all carried to review-ready PRs in one unattended pass. For a single issue, use `/autopilot` directly.

Where this runs (read first)

Run this **from the target application repository** — the repo whose issues and app these are (e.g. the Rails app) — on a clean default branch, pulled up to date. **Not from dotfiles.** `isolation: worktree` creates each worktree from the _orchestrator's current repo_, so the cwd decides where the fan-out worktrees land; running from the wrong repo produces worktrees of the wrong tree. If the cwd is the dotfiles repo (or any repo that doesn't own these issues), stop and say so.

Arguments

• **(no args)** — run every `autopilot-queued` issue at tier `--to pr`. The whole batch stops at review-ready PRs; nothing merges.
• **`--merge <issue#,…>`** — authorize tier `--to merge` for the listed issues only (e.g. `--merge 847,851`). Everything else stays `--to pr`. Merge is still gated per issue by `/autopilot`'s Step 8 narrow-class gate, which degrades any non-qualifying issue back to `--to pr`. Passing `--merge` IS your per-issue authorization to merge those issues; it is not a standing capability.

Default tier is `--to pr` by design — merge is opt-in, per issue, never batch-wide.

The build-model policy — the label decides the build, review runs at Opus or above

Each issue's _build_ subagent runs at a model chosen per issue; the _gating review_ always runs at **Opus 5 or above, and never below the build**. Ladder, cheapest to most capable: **Sonnet 5 → Opus 5 → Fable 5**.

Resolving each issue's build model

**Read the issue's `model:` label first.** Repos that have adopted the per-issue model convention (`~/.claude/docs/model-selection-strategy.md`) carry one on every open issue, recording the build tier assigned at triage. Step 1's issue list already returns labels, so no extra call is needed:

• `model: sonnet` → build with **Sonnet 5**; `model: opus` → **Opus 5**; `model: fable` → **Fable 5**.
• **No `model:` label → fall back to the class rubric below.** Most repos have not adopted the convention and must keep working unchanged; in an adopted repo, unlabeled means Opus by convention — which the rubric already approximates — so the same fallback is right in both worlds.

The fallback rubric, unchanged:

• **Opus 5** — data-model / migrations, auth / security boundaries, inventory / shipment correctness, thin or ambiguous specs, cross-cutting refactors. Also the model whenever you genuinely can't tell the class (safe default — Opus never under-builds).
• **Sonnet 5** — bounded, well-specified, pattern-following work: i18n / copy, views / Tailwind, config, a single test, straightforward CRUD, docs.

State each issue's model at the confirm gate **and where it came from** — `label` or `rubric (no label)` — with a one-line why for every rubric call. An override you make at the gate is worth writing back to the issue's label afterward, so the record stays honest for the next run.

The review tier is derived, never labeled

The gating review (Step 4) is computed from the build tier and is never read from the label. One invariant: **review runs at Opus 5 or above, and never below the build.**

| Build | Gating review | | --- | --- | | Sonnet 5 | Opus 5 | | Opus 5 | Opus 5 (fresh context, adversarial prompt, independent sample) | | Fable 5 | Fable 5 (ceiling) |

This is the structural safety net: an under-build is caught and fixed at review, never shipped. That is exactly what makes leaning on the cheaper tier for the bulk close to free on quality while saving real latency and limit headroom at fan-out scale — so **a `model: sonnet` label must never downgrade the review.** It sets the build only.

The floor replaced a "one tier above the build" rule on 2026-07-27. That rule was written to insure _cheap_ builds; Opus was never the cheap build, and at fan-out scale it sent nearly every review in the batch to Fable. A Fable review is now reached by **escalation rather than by rule** — via a `model: fable` label, via a mid-flight escalation (the table reads the model the build _actually ran at_), or by simply re-spawning the reviewer at Fable on the PR. See `~/.claude/docs/model-selection-strategy.md` § "The review floor, and the trade it accepts" for the reasoning and the trade it knowingly accepts.

Merge issues are always Fable-built

A build subagent runs the whole `/autopilot` loop at **one** model (a subagent can't switch mid-run), so whichever model builds a `--to merge` issue also makes its merge go/no-go inside `/autopilot` Step 8. The floor is non-negotiable: the merge decision is always Fable — the autonomous merge is the highest-stakes call in the pipeline, so it gets the most capable model. Therefore: **any issue opted into `--to merge` is built by Fable**, regardless of what its `model:` label or the class rubric would otherwise pick — a `model: sonnet` label on a merge-tier issue does not buy a cheaper merge decision. Sonnet and Opus only ever build `--to pr` issues, which stop at a review-r