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)

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 ("will stop at review-ready PR" / "will merge + deploy if the narrow-class gate passes"), and the model reconciliation from the section above (the issue's model: label, the model you are running, and the verdict — match / no label / over-model note / stopping on an under-model). Confirm you are starting from an appropriate base (a clean main/master, or an existing worktree branch for this issue). Then work the loop:

Step 1 — Resolve

Invoke /resolve-issue <number> and let it run its 6 steps, with these autopilot overrides:

• Honor its planning checkpoint as the escape hatch above. Proceed autonomously for a small, well-scoped issue; stop and ask for a complex/ambiguous one.
• Override its Step 6 stop. /resolve-issue ends by asking whether to create a PR — in autopilot, do not stop there; continue the loop.
• Commit protocol: follow the global CLAUDE.md file-based commit flow (write the message with the Write tool, git commit -F .git_commit_msg, remove it). Never put $(...) or backticks in a commit command.
• AC checkboxes are best-effort and must never block the run. If /resolve-issue checks off acceptance-criteria boxes, use gh issue edit <n> --body-file <file> (never --body "$(...)", which the auto-mode classifier flags). If the write still prompts or fails, skip it and note "AC boxes left for manual check-off" — the real issue↔PR link is Closes #N in the PR body, so the checkboxes are cosmetic.

Step 2 — Simplify

Invoke /simplify to review the changed code for reuse, simplification, and efficiency, and apply the fixes. Commit any resulting changes (file-based commit flow). This is quality-only; it does not hunt for bugs.

Step 3 — Create the PR

Invoke /create-pr. It infers the issue from the branch name and opens a ready-to-review PR with Closes #<number>. Capture the PR number for the next steps. (Per the project workflow, the PR is opened before verify/walkthrough by design — the diff is reviewable while those checks run.)

Steps 4–5 — Verify and Walkthrough (user-facing changes only)

Match the verification to the change's actual surface — don't reflexively invoke /verify:

• Visible / interactive surface (a page, form, or flow a user drives): invoke /verify <PR> then /walkthrough <PR>. Both may report "not applicable" and exit — that's expected; skip them when they do.

• Runtime behavior but no visible surface, fully test-covered (e.g. i18n key resolution under raise_on_missing_translations, a config value, a computed default): substitute a targeted inline verification for the browser /verify — run the specific test or exercise the behavior directly to confirm it resolves, and note what you checked in the debrief. A browser walkthrough adds nothing here, so skip it.

• No runtime surface at all (docs, comments, a pure refactor with green tests): skip both.

• QA is local-dev-only. The app is POST-LAUNCH (real distributor data). Never drive the production site — no walkthroughs, /verify, or data-mutating flows against live. Local dev only. (See project CLAUDE.md "QA Testing Policy".)

• Start the app the headless-reliable way, never bin/dev (its Tailwind watcher exits without a TTY and foreman SIGTERMs the whole group, killing the server). Use:

  bin/rails tailwindcss:build   # one-shot compile
  bin/rails server              # separate process

• For 375px mobile checks use the chrome-devtools emulate tool (true viewport), not window resize. Assert window.innerWidth and no horizontal overflow.

• Do not run /walkthrough --publish — publishing stays a human-gated action.