/autopilot
Autonomous work loop — picks up issues, implements, QAs, PRs. Stops for merge approval.
Synopsis
/autopilot [issue_number] [--dry-run] [--urgent-first|--least-first]
When to use it
- You have a backlog of GitHub issues and want them worked methodically: assess → classify risk → verify → plan → implement → QA → self-review → PR
- You want a junior-engineer workflow with guardrails — risk scoring before any code, escalation when unsure, and a mandatory human gate at every PR
- Not for: one open-ended objective where the path is unknown — that’s /goal, the speed-first single-objective loop; /autopilot is rigor-first and queue-driven, with full P0–P5 ranking and per-item risk classification
- Not for: a single bug you already understand — /fix is faster
Quickstart
/autopilot --urgent-first
What you’ll see: the open issues and PRs ranked P0–P5, then the loop starts on the most urgent item. It self-paces through implementation and QA, opens a PR, and stops — it never merges. After you merge, it picks up the next item automatically.
Examples
/autopilot # rank the backlog, ask which direction to work
/autopilot 141 # work just issue #141
/autopilot --urgent-first # P0 → P5: critical items first (recommended default)
/autopilot --least-first # P5 → P0: warm up on small items
/autopilot --dry-run # show the ranked queue and plan without doing anything
Arguments & flags
| Flag |
Values |
Default |
What it does |
issue_number |
— |
none |
Skip ranking, work this issue only |
--dry-run |
— |
off |
Assess and classify only; report what it would do — good for trust-building |
--urgent-first |
— |
— |
Work the queue P0 → P5 |
--least-first |
— |
— |
Work the queue P5 → P0 |
What it does
- Assess — scans open issues, your PRs, and review comments; ranks everything P0 (critical) to P5 (nice-to-have) using labels and impact rules. If no direction flag was given, it asks you — user-confirmation checkpoint. Vague issues without acceptance criteria are flagged for your triage, never auto-picked.
- Classify risk — scores blast radius, reversibility, confidence, and domain sensitivity (0–12). Low risk proceeds autonomously; 6–8 proceeds with notice; 9–10 stops and asks — user-confirmation checkpoint; 11–12 is refused. Migrations and auth/payment code always escalate.
- Verify — reproduces the bug before touching code; stale already-fixed issues get closed instead of “fixed” again.
- Plan — defines expected files/layers and objective completion criteria (each with a verifiable
done_when clause).
- Implement — simple fixes inline; multi-file work via backend/frontend agents plus a QA agent. Every commit and test run is captured in an evidence log.
- QA — runs tests, lint, type checks (2 fix attempts max, then it escalates).
- Self-review — a separate gate after QA passes: checks scope growth (>1.5x planned stops the loop), hardcoded values, error handling, security, test coverage, and unintended changes; re-assesses risk now that code exists. Unrelated bugs found along the way are filed as issues, not fixed inline.
- PR — mandatory stop — opens a PR whose body is assembled from the evidence log, then stops and waits for your merge approval — user-confirmation checkpoint. It never merges. While waiting, it pre-assesses the next item.
- Post-merge — checks CI on main (auto-reverts and reopens the issue if its merge broke CI), records learnings, then loops to the next item. Once this completes, a completion-verifier agent checks the item’s evidence against its completion criteria (see below).
Agents spawned
| Agent |
Model tier |
Role |
| backend / frontend |
sonnet |
Implementation, per the plan’s layers (simple fixes run inline with no spawn) |
| qa |
sonnet |
Reviews and validates alongside implementation agents |
architect (opus) is not spawned directly by autopilot — for risk-6+ features, Phase 4 (PLAN) delegates to the /planning skill, which spawns architect itself.
Post-merge verification: after a work item’s full lifecycle completes, autopilot spawns completion-verifier (sonnet) to check the item’s evidence against its completion criteria. It reports PASS, GAPS FOUND, or INCONCLUSIVE — gaps don’t block, you decide whether to rerun.
Output & artifacts
- One PR per work item, with risk assessment, scope check, evidence, and QA results in the body
.claude/.workflow-state.json — durable loop state: queue, current item, evidence, session summary (resume anytime with /autopilot)
- Issues filed for problems discovered along the way; learnings appended to
.claude/knowledge/skills/autopilot.md
Troubleshooting
| Problem |
Fix |
BLOCKED: Can't resolve test failure after 2 attempts |
The loop escalates instead of thrashing — investigate and give guidance |
SCOPE: Started at 3 files, now at 6 |
Scope guard fired — approve the growth or trim the change |
COST: This item has used 6 agent spawns |
Per-item budget hit — continue, skip, or split the issue into smaller ones |
| Issue skipped as unrankable |
It has no acceptance criteria — add them to the issue and re-run |
| Loop stopped and you want it back |
/autopilot resumes from .claude/.workflow-state.json; saying “stop” or any unrelated request pauses it |
- /goal — single-objective, speed-first counterpart; both stop at PR creation
- /fix — the formal bug pipeline autopilot’s rigor is modeled on
- /pr — manual PR workflow for work you drive yourself
- /tech-debt — autopilot auto-runs an audit every 3 completed items