← Files fstackARCHIVED FILE
skills/engineer-mode/playbooks/autopilot-full.md
5.37 KB · Oct 4, 2026 · 12:34 UTC
### Autopilot-full **You own the verdicts, never the PRs. One owner runs each PR from build to merge-ready, and nothing merges without both your clean swarm verdict and the operator's explicit merge click.** For "autopilot this queue", "full autopilot", and one-owner-per-PR programs. The job is a queue of independent PRs handed over to drive to merge-ready with full autonomy; the operator clicks every merge. Orchestrate runs a standing program whose coordinator lands verified work itself and whose workers never merge; here each PR's owner carries the whole lifecycle up to merge-ready, the operator clicks the merge, and the root keeps only verification, countersigns, and audits. 1. **Mark the operator's items and honor state-then-wait.** Items the operator names stay hers. She reviews and she clicks, and no owner merges one. When she asks for the protocol or the plan to be stated, deliver the statement and stop. Execution starts only on her explicit go. On that go, write the full program objective into the standing orders and restate it in your todolist, since Claude Code has no `/goal` command. That objective stands across turns until the queue is done. 2. **Spawn one owner per PR with the full lifecycle.** One background subagent per PR, in its own worktree, owns build, a ready PR, self-proof on the real artifact (the **prove-it-works** principle skill), skeptical review-bot triage per `../references/bugbot-triage.md`, a slop-strip (the **deslop** skill, `/deslop`), `/no-comments` (the **no-comments** skill), a rebase onto current trunk, and the babysit loop to green (`playbooks/babysit.md`). The rebase always precedes babysit and never waits for drift or conflicts. Every owner keeps a decisions.tsv trail per the **show-me-your-work** skill, never committed, returned with its reports. The owner drives to merge-ready and stops there. No owner runs the merge; step 4 gates the verdict and step 5 hands the merge to the operator. 3. **Run owners in true parallel and never stack.** Many owners at once when PRs are self-contained: one writer per branch, disjoint files, cross-PR drift absorbed by rebase. Only genuinely overlapping work serializes. Self-contained PRs branch straight off main, and sequenced work is merge-then-branch. One exception: an owner that must split a genuinely dependent change may hold a short private base-branch stack. 4. **Swarm-verify every merge-ready head before its merge.** At the owner's merge-ready head SHA, fan out parallel independent verifiers per the **swarm** skill and aggregate to one verdict. The fan-out mechanics live there; do not restate them. The lanes: re-run the gates at that SHA; prove the load-bearing behavior live on the real surface the change touches (the `run` skill for CLIs and TUIs, `verify` for UIs, as the change demands); audit the receipts and the diff, distrusting the PR body. The live lane is the floor, and a verdict without it is not clean. No merge without the root's clean verdict. Findings go back to the owner for fix-forward, and the new head gets a fresh swarm and a fresh verdict. 5. **On a clean verdict the owner hands off and takes the next item.** The merge-ready head must be freshly rebased on trunk. The merge-ready report is made at a trunk-current head, and the swarm verdict pins that SHA. If trunk moves again before the operator merges, the patch-id rule in `playbooks/shipping.md` governs re-verification; a new head voids the verdict unless the patch-id is unchanged. The owner presents the verified merge-ready PR to the operator, with its swarm verdict and pinned SHA, then picks up its next self-contained item from the queue. The operator reviews and squash-merges; no owner runs the merge itself. Every item waits for the operator's click, the gate operator-named items always had; the root's clean verdict is a precondition for that click, never a substitute for it. 6. **Run the root layer.** A genuinely new raise of a pinned gate or budget value (a limit CI only lets tighten) needs your fresh countersign, granted only after verifier proof. Absorbing values that already landed on main is drift, not a raise. Run an audit tick over all owners roughly every 30 minutes. Arm each tick as a real `/loop` in dynamic mode, which schedules its own wake-up rather than blocking on a sleep. Never leave the cadence to memory or lossy completion notifications. At each tick, re-read this playbook from disk (`skills/engineer-mode/playbooks/autopilot-full.md` under the installed plugin), then re-read the standing objective. Audit the operation against both. Fix drift during that tick and treat it as urgent. Probe each owner with a generic liveness or status check, and collect the decision trails. Count only side effects as progress: commits, pushes, PR or check deltas, and store reports. Treat a lane that passes its expected runtime without a side effect as stuck. Stand it down and dispatch a replacement at once. Do not wait for a polite return. When merges batch, run a retro pass and a post-merge bot-comment sweep. 7. **Stand down instantly on the operator's stop.** Her hold or stand-down reaches every owner as a zero-writes order immediately. Owners hold their briefs until she releases them. **Reply:** the queue with each PR's owner, state, and head SHA; each verdict and the swarm that produced it; what merged and what each owner took next; countersigns granted and why; open operator gates; where the collected decision trails live.
SHA-256: b503bf099454e63d18a80cce135b45f0e9726d7de1e20a09ef6ee72e04f5f59f