/autopilot

name: autopilot
description: Carry a well-scoped GitHub issue through the full dev loop autonomously, stopping at a per-run tier boundary (PR-ready, or merge+deploy for small reversible changes).
argument-hint: "[issue-number] [--to pr|merge]"

Autopilot

Drive a single GitHub issue through the project's full development loop with minimal supervision, stopping at a boundary you authorize up front. This composes the existing skills (`/resolve-issue`, `/simplify`, `/create-pr`, `/verify`, `/walkthrough`, and the built-in `review`) plus `bin/ci` — it does not reinvent them.

Use this when an issue is clear and well-specified and you want it carried to a review-ready PR (or, for small reversible changes, all the way to merge) without invoking each step by hand. For issues that need close collaboration, use the individual skills instead.

Arguments

`$ARGUMENTS` contains the issue number and an optional tier flag:

• **`--to pr`** (default): run the full loop and **stop at a review-ready PR**. No merge, no deploy. This is the well-lit path — the human merge gate catches everything.
• **`--to merge`**: run the full loop, then merge (which auto-deploys) **only if the change passes the narrow-class gate** in Step 8. Otherwise it degrades to `--to pr` and stops. Passing `--to merge` IS your per-run authorization to merge this one issue; it is not a standing capability.

Examples: `/autopilot 754` (→ pr), `/autopilot 754 --to pr`, `/autopilot 847 --to merge`.

Parse the issue number and tier from `$ARGUMENTS`. If no tier is given, default to `pr`. If the tier is unrecognized, stop and ask.

Build model — reconcile against the issue's `model:` label

Repos that have adopted the per-issue model convention (`~/.claude/docs/model-selection-strategy.md`) carry a `model: fable` / `model: opus` / `model: sonnet` label recording the **build** tier chosen at triage. Read it as part of the announce:

gh issue view <n> --json labels --jq '[.labels[].name | select(startswith("model: "))] | first // "none"'

Autopilot cannot _act_ on that label the way `/autopilot-batch` does — a running agent cannot switch its own model, so this skill still runs at whatever model invoked it. What it can do is reconcile before any work starts. Ladder, cheapest to most capable: **Sonnet 5 → Opus 5 → Fable 5**.

• **No label** — the common case, and never a reason to stop. Either the repo hasn't adopted the convention or triage hasn't reached this issue; fall back to the existing judgment (announce that you're proceeding on the invoking model) and run.
• **Session model matches the label** — say so in one line and proceed.
• **Session model is _below_ the labeled tier** (e.g. Sonnet running a `model: opus` issue) — **stop and ask.** This is an under-build, the direction that produces quietly wrong work, and the announce is the cheapest possible moment to catch it. Report the mismatch and recommend re-invoking at the labeled tier. **Exception:** if whoever invoked you states the lower tier was chosen deliberately — an `/autopilot-batch` override at its confirm gate is the usual case — the human gate already happened. Note the deliberate downgrade and proceed.
• **Session model is _above_ the labeled tier** (e.g. Opus running a `model: sonnet` issue) — note it once and **proceed.** Over-building costs plan-limit headroom, not correctness, and halting an authorized run over a consumption preference is the worse trade. Carry the note into the completion report so the pattern shows up if it repeats.

**The label governs the build only.** It never lowers a derived tier: the review tier in Step 6 and the `--to merge` gate in Step 8 are unaffected, and **the merge go/no-go floor stays Fable regardless of any label** — a `model: sonnet` issue does not get a cheaper merge decision. (In a batch run, `/autopilot-batch` enforces that floor by building every `--merge` issue with Fable, and applies the standing review floor — Opus or above, never below the build — to every `--to pr` PR.)

If the issue body opens with a **model callout** (a `> 🤖 Recommended model: …` blockquote), it names the watch-item or escalation trigger behind the tier choice — read it, treat it as part of the spec, and watch that specific thing during Step 1.

**Escalation is the escape hatch, not a silent upgrade.** If the work proves materially harder than the label assumed, stop, report what you hit, and recommend re-running at a higher tier — noting that the issue's label should be updated afterward so the record stays honest.

The "stop and ask" escape hatch (applies to every step)

Autopilot is autonomous, not reckless. **Stop immediately, report what you found, and wait for the user** if any of these arise — do not guess or push through:

• The `/resolve-issue` planning checkpoint (Step 3 of that skill) judges the issue **complex or ambiguous** — multiple subsystems, real design choices, or unclear acceptance criteria.
• The issue's `model:` label names a **higher tier than the model you are running** (see "Build model" above) — an under-build, caught before any work starts.
• A decision surfaces that the project's own guardrails reserve for the user: a **new DB column not in the data model, a changed model association, an altered public URL, a new dependency, or a change to the event status lifecycle** (see the project CLAUDE.md "Handling Ambiguity" table).
• Tests fail in a way you cannot confidently resolve, or a fix would require inventing scope beyond the issue.
• The spec conflicts with what you find in the code (three valid responses per global CLAUDE.md: implement as written, ask, or propose a change — the latter two mean stop).
• A permission prompt blocks progress and there is no compliant alternative path.

When you stop, post a concise summary: what's done, where you stopped, exactly what you need from the user, and the recommended next command.

Your task

Announce the run first: issue number, tier, the boundary ("wil