Add /autopilot — run the full yoke flow end-to-end

[prineycom]

Add /autopilot — run the full yoke flow end-to-end

Description

Today a user has to manually drive yoke through the full pipeline:

/task → /plan → /do → /review → /fix (if needed) → /gca → /gp → /pr

Each step is a separate invocation with a hand-off in between. For routine tickets this hand-off is pure overhead — the user already knows they want "take this ticket and land a PR."

/autopilot compresses the whole pipeline into a single command that runs end-to-end, stopping only for (a) errors, (b) user-configured checkpoints, or (c) explicit ambiguity that the model cannot resolve safely.

Behavior

Invocation

/autopilot <ticket-url-or-description>
/autopilot                              # resumes from the last artifact if no argument

Pipeline

1. /task — produce task file (kept as an artifact under .claude/tasks/)
2. /plan — build the implementation plan; stores plan file alongside the task
3. Checkpoint (default: on) — show task + plan summary, ask to proceed
4. /do — execute the plan, produce working-tree changes
5. /review — run the review skill over the produced diff
6. /fix — if /review flagged blocking issues, run /fix against them; re-review. Cap at N iterations (default 2) to prevent infinite loops.
7. /gca — stage and commit with smart grouping
8. /gp — push (with the standard safety checks)
9. /pr — open or update the pull request
10. Summary — print links to task, plan, review report, commits, and PR

Flags

• --from <step> — start from a given step (e.g. --from do skips task/plan generation, assumes artifacts already exist)
• --stop-at <step> — stop after a given step (e.g. --stop-at do leaves the diff uncommitted for manual inspection)
• --no-checkpoints — run fully unattended (still stops on errors)
• --checkpoints <task,plan,review> — list of explicit checkpoints; defaults to plan,review
• --max-fix-iterations <N> — cap the /review ↔ /fix loop (default 2)
• --dry-run — plan the pipeline and print what would run without executing mutating steps (/do, /gca, /gp, /pr)

Stop conditions

Autopilot MUST stop and hand control back to the user when:

• /task or /plan produces something the user explicitly asked to review (checkpoint)
• /do hits a failing test, type error, or lint error it cannot resolve within plan scope
• /review returns blocking issues AND the fix loop is exhausted
• /gca would commit files that look sensitive (.env, credentials, keys)
• Pre-commit / pre-push hooks fail
• PR base branch protection rejects the push
• Any step fails twice with the same error

Artifacts and resumability

Each step writes a durable artifact:

.claude/
  tasks/<slug>.md          # /task output
  plans/<slug>.md          # /plan output
  reviews/<slug>-<n>.md    # /review output(s)
  autopilot/<slug>.log     # timeline of steps + exit codes

/autopilot --from <step> reads existing artifacts, so a failed run can be resumed without re-deriving earlier work. This matters for two reasons:

• Token cost — we don't want to re-run /task + /plan just because /do hit a flaky test
• Determinism — the user can hand-edit the plan and re-run from /do

Safety rules

• Never skips hooks (--no-verify) unless the user explicitly passes it through
• Never force-pushes
• Never touches main/master directly — always goes through a feature branch
• Never runs destructive git operations (reset --hard, branch -D, checkout .) automatically
• Respects --dry-run fully: no commits, no pushes, no PR writes
• The /review → /fix loop is capped; hitting the cap escalates to the user instead of retrying silently

Open questions

• Default checkpoint set. Aggressive defaults (stop at every major artifact) make autopilot feel like a wizard. Minimal defaults (stop only on error) make it feel autonomous. Proposal: default to plan,review — stop after plan (so the user can edit scope) and after review (so the user sees findings before commit).
• Branch handling. Does autopilot create a new branch for each run, or assume the current branch is correct? Proposal: if on main, create a branch from the task slug; otherwise use the current branch.
• Ticket source. /task already accepts URLs and free-form descriptions. Autopilot inherits that — no new parsing needed.
• Interaction with /yoke:bootstrap. If the project hasn't been bootstrapped, should autopilot refuse, or run bootstrap first? Proposal: refuse with a clear message — bootstrap is a one-time setup and should be a conscious choice.

Acceptance criteria

• /autopilot <ticket> runs task → plan → do → review → fix? → gca → gp → pr end-to-end on a happy-path ticket
• Default checkpoints (after plan, after review) surface a concise summary and wait for the user
• --no-checkpoints runs fully unattended on the happy path
• --from <step> correctly resumes from the given step using existing artifacts
• --stop-at <step> halts after the requested step and prints the artifact path
• --dry-run runs non-mutating phases and prints the planned actions for mutating phases without executing them
• On any failure, autopilot stops, prints the failing step + error, and leaves the working tree in a recoverable state
• Review ↔ fix loop honours --max-fix-iterations and escalates when exhausted
• Never pushes to main/master, never force-pushes, never skips hooks without explicit flag
• Final summary prints paths to every artifact and the PR URL
• SKILL.md documents all flags, checkpoints, stop conditions, and the resumability model

References

• Existing skills to compose: /yoke:task, /yoke:plan, /yoke:do, /yoke:review, /yoke:fix, /yoke:gca, /yoke:gp, /yoke:pr
• Plan/execute decomposition pattern: superpowers executing-plans, writing-plans

---

Migrated and expanded from projectory-com/sp#23.