Autopilot

---
description: Drive a specced feature to completion autonomously — all phases, review, fixes — in a dedicated worktree by default. Stops at /done on the branch (merge to main stays human/opt-in).
argument-hint: [slug] [--here] [--merge]
---

You are about to **autonomously drive an already-specced feature to completion**: every
implementation phase, the review, and the fixes — then stop with the feature promoted on its
own branch, ready for a human to merge.

This command is a **thin driver**. It does **not** reimplement any dispatch logic. It *composes*
the existing slash commands — `/next-phase`, `/feature-review`, `/resolve`, `/done` — by invoking
them in sequence (via the Skill tool, exactly as if a user typed them), and owns **only** the
parts they don't: the worktree wrapper, the loop + termination, the retry budget, the orchestrator
chore-commits between steps, and the hard-stop conditions. Treat the four sub-commands as the
single source of truth for *how* each step dispatches; never duplicate their bodies here.

## Args from the user

$ARGUMENTS

Parse: the first non-flag token is `<slug>` (required). Flags:

- `--here` — **opt out of the worktree.** Run the whole pipeline in the current checkout instead
  of a sibling worktree. (Default is worktree-per-feature so concurrent work isn't blocked.)
- `--merge` — **opt in to auto-merge.** After `/done`, also merge the branch into `main`. Default
  is to **stop before merging** and hand that judgment to a human.

If no slug is given and exactly one feature is in `.kanban/2-in-progress/`, infer it; otherwise
list the active features and stop.

---

## How this command behaves (read before running)

- **Resumable.** Every step leaves a clean tree and an advanced `checkpoint.yaml`. Re-invoking
  `/autopilot <slug>` after any interruption re-enters the worktree and picks up from checkpoint
  state — it never restarts work already committed.
- **Cost.** A full run executes the entire `dotnet test` suite **at least 3×** (both
  `/feature-review` passes + `/done`'s `final_verify`), on top of each phase's `verify-phase`. On a
  large feature that is real wall-clock time — expected, not a hang.
- **Two hard rules that override everything below:**
  1. **Hard gates are never retried or forced past.** A red `verify-phase`, a red `final_verify`,
     a merge conflict, or a post-merge-red → **STOP immediately, leave the tree exactly as it is,
     and write a handoff** (what failed, the exact command to resume). Never edit code to force a
     gate green outside the normal phase/resolve flow.
  2. **Soft failures get 2 attempts, then stop.** A phase or a finding that the sub-agent cannot
     resolve after **2 total attempts** → STOP + handoff. Do not loop a third time.

---

## Step 1 — Preconditions (run in the **main checkout**, before any worktree)

Stop on the first failure and tell the user how to fix it.

1. **Spec exists and is committed on `main`.** `worktree-start` branches from the *committed*
   `main` ref, so an uncommitted spec won't carry into the worktree.
   ```bash
   git -C . rev-parse --abbrev-ref HEAD          # expect: main  (or run --here)
   [ -d ".kanban/2-in-progress/$SLUG" ] || { echo "no spec for $SLUG — run /spec first"; exit 1; }
   [ -z "$(git status --porcelain .kanban/2-in-progress/$SLUG)" ] \
     || { echo "spec for $SLUG is uncommitted — commit it on main first"; exit 1; }

2. Spec validates.

   stash scripts/checkpoint/checkpoint.stash validate-spec "$SLUG"
   

   If this fails, the brief/plan needs the architect — stop and say so (/spec).
3. Pin main for the split-brain guard. Record main's SHA now, in the main checkout — you pass it to assert-phase-landed --main-ref each phase so a worktree run can prove its commits never leaked onto main:

   git rev-parse main      # remember this SHA — referred to as <MAIN_REF> below
   

   (Under --here there is no worktree, so the pin is moot — skip --main-ref in Step 3.)

Step 2 — Enter the worktree (default) / resume / --here

• --here: skip this step entirely. Work in the current checkout. (No merge step at the end — the work simply lands wherever you are.)
• Worktree already exists (../stash-<slug> + feature/<slug> present — an interrupted prior run): do not call worktree-start (it refuses on collision). Just re-enter it:

  EnterWorktree  path: ../stash-<slug>
  

• Otherwise — create it:

  stash scripts/checkpoint/checkpoint.stash worktree-start "$SLUG"
  

  then EnterWorktree path: ../stash-<slug>. Once inside (cwd is now the worktree, with its own .kanban/ and scripts/), run the parallel-safety heads-up and surface its warning but do not stop (it is non-blocking, exit 3):

  stash scripts/checkpoint/checkpoint.stash check-parallel-safety "$SLUG" || true
  

Everything from here runs inside the worktree (or the current checkout under --here), so the sub-commands resolve all paths locally — no cross-checkout orchestration.

Step 3 — Phase loop (until all phases done)

Repeat until stash scripts/checkpoint/checkpoint.stash status "$SLUG" shows every phase done:

1. Invoke /next-phase <slug> (Skill tool). One implementer, one phase. /next-phase already runs its own pre-flight (validate, clean-tree check, get-next-phase) and its own post-dispatch verification + implementer chore-commit fallback — let it.
2. After it returns, assert the phase landed with the deterministic verdict (replaces eyeballing status.stash + git status by hand). In worktree mode add the --main-ref pin from Step 1 so a stray commit onto main is caught:

   stash scripts/checkpoint/checkpoint.stash assert-phase-landed "$SLUG" "<phase-id>" --main-ref <MAIN_REF>
   

   (Drop --main-ref under --here.) A non-zero exit means the phase did NOT land cleanly — dirty tree, phase not done/`verified