/autopilot

name: autopilot
description: >-
  The whole coding loop on one deliberate yes: map, spec, critic-hardened
  plan, GitHub issues, parallel worktree implementers, fresh-context review
  loops, one PR with the evidence. Acts only on its itemized charter; parks
  what it can't settle honestly. Commands: /autopilot <task> [--merge],
  resume, status. It signs a charter and pushes branches, so it never
  auto-triggers — explicit invocation only.
disable-model-invocation: true

autopilot — the whole loop, one yes

`/autopilot <task>` — run the full pipeline, stop at an open PR `/autopilot <task> --merge` — also merge, once every gate is green `/autopilot resume <change>` — pick up a crashed, aborted, or parked run `/autopilot status` — report runs in flight under `out/dev/`

Answer one question: **what would come back if this task were handed to a careful team and nobody watched over their shoulder?** The other coding skills put a human at every gate; this one replaces those gates with the things that made them work — fresh-context review, diverse critique, and a test suite as the arbiter — and reserves the human for exceptions. Human *on* the loop, not *in* it: you sign once, you get a PR, and anything the pipeline couldn't settle honestly comes back **parked**, not guessed.

The charter — one yes, spelled out

The invocation is the consent. Echo this before running, then don't ask again:

• **WILL:** read anything in the repo; write state under `out/dev/<slug>/`;

create GitHub issues labeled `autopilot`; create and push branches `autopilot/<slug>/*`; open **one** PR; comment on and close its own issues; with `--merge`, merge that PR once every gate is green.

• **NEVER:** push to the default branch directly, force-push, rewrite

history, delete branches or issues it didn't create, weaken a test to get green, or touch anything outside this repo.

Auto mode — how the other skills run here

Autopilot drives **map**, **feature**, and **done** in *auto mode*, a shared convention: every approval gate becomes a self-approval **on the record** — the decision and its reason are appended to `log.md` instead of asked — and every verdict that would need a human becomes a **PARK**. The skills' own rules (task sizing, TDD, tripwires, never-weaken-tests) are unchanged; only the waiting is removed. In auto mode the run **never calls a tool that stops to wait on a human — `AskUserQuestion` first among them** (waiting on sub-agents or commands is fine): with nobody watching, such a call isn't a question, it's a deadlock. A decision only a human can settle is parked with the decision spelled out — never waited on, never guessed.

Step 0 — Preflight

• Confirm: a git repo, a clean tree, `gh` authenticated. Without `gh`,

degrade honestly — local task files instead of issues, stop at the branch instead of a PR — and say so in the run header.

• Find the test command (`AGENTS.md`, `package.json`, `Makefile`,

`pyproject.toml`, CI config). **No test suite?** Don't refuse — schedule a **testing-bootstrap phase** as the plan's first wave: stand up the runner, then write characterization tests around exactly the code the plan will touch. Without an objective test to pass, every review loop below is just one model agreeing with another; the bootstrap fixes that.

• Open `out/dev/<slug>/log.md` with the run header: charter, stop point

(PR / merge), test command, start commit.

Step 1 — Orient

Run **map** in auto mode: no `AGENTS.md` → generate one; one exists → refresh only if stale. Every downstream agent starts oriented instead of cold.

Step 2 — Spec: interview the codebase, not the user

**feature** Step 1 with the questions turned inward — the facts-vs-decisions split holds with no user present. Every *fact* is answered by reading code, docs, tests, and `git log`; whatever evidence can't settle — an open decision or an unverifiable fact — is never resolved silently: it becomes a numbered assumption (**A1…**) in `spec.md`, visible and revisable at the PR, where wrong assumptions are cheap to catch. The spec remains the contract every review below is judged against.

Step 3 — Plan, hardened by critique instead of approval

Write `plan.md` per **feature** Step 2 — 2–5-minute tasks, exact files, own verification step, dependency order. Then replace the human approval with a **bounded critique loop**: parallel critic sub-agents, each with a different lens — feasibility, hidden dependencies & ordering, test coverage, scope creep — each returning *blocking findings or an approval*. If another model's agent CLI is installed (detect per **done** Step 2), give one critic seat to it: fresh context varies the perspective, a different model varies the blind spots. Fix the blocking findings, re-run the critics once. **Two rounds maximum**: past that, critique stops finding real problems and starts agreeing with itself. Surviving blocking findings park the run at the plan stage — a plan the critics can't pass is the user's call, not a coin flip.

Step 4 — Tasks become GitHub issues

One issue per plan task, **created in dependency order** so every `depends-on: #n` names a real number: the full briefing (a fresh agent must be able to execute from the issue text alone), the files it touches, its verification command, and the spec IDs it implements (`[D2, A1]`, where one applies). Label `autopilot`, title `[<slug>] <task name>`. Record issue numbers back into `plan.md`. Issue prose describes **behavior, not code** — "the sync service drops the patch", never `applyPatch()` at line 42, no file paths or line numbers in prose; analysis artifacts cite file:line because they're verified now, tracker artifacts must outlive the refactor. (The files-touched list stays — it's the worker's briefing, not durable prose.)

Local files stay canonical; the issues are the published mirror — and the hand-off that actually reaches the workers, since the run's `out/` state is uncommitted mid-run and i