| name | autopilot |
| description | Optional explicit Blueprint mode for one bounded spec/build/check pass. It can pick or resume the current feature, write the spec when needed, create or reuse the branch, implement small steps, run build/tests/checks, create checkpoint commits after passing steps, self-review the diff, and stop with a review packet. It never completes, merges, pushes, deploys, publishes, sends, or performs destructive actions without explicit approval. Use only when the user explicitly runs /autopilot, invokes $autopilot, or directly asks for Autopilot. |
autopilot - optional Blueprint loop
Where this sits in the workflow:
/status -> [autopilot] -> review packet -> /complete
(where (spec, build, (human review, (log, commit,
are we?) check, review) fixes if needed) merge with approval)
Autopilot is an explicit opt-in path. It uses the same Blueprint files and the
same quality gates, but it does not stop after every normal review point. A
single user request is permission to run one bounded loop until the feature is
ready for review, blocked, or unsafe to continue.
It does not replace the normal workflow. /feature, /implement, /check,
and /complete remain the conservative default.
Do not suggest Autopilot as the default next action. Use it only when the user
explicitly asks for it.
The explicit Autopilot request is permission to create checkpoint commits on the
feature or fix branch after passing implementation steps. It is not permission to
merge, push, deploy, publish, send, delete data, or run destructive actions.
Input
Common forms:
- No argument: resume the current feature if one exists, otherwise target the next
unchecked build-plan item.
- A number or name: target that build-plan feature, for example
/autopilot 3 or
$autopilot "directory listing".
- : write and build an ad-hoc fix spec.
