Autopilot

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)