Use when the user wants an unattended specflo run — "auto mode", "autopilot", "run it on its own", "keep going without me", "don't stop to ask" — map that to `specflo auto`. It is an explicit, per-invocation opt-in that drives the pipeline across phase boundaries without the ask-first pause. Do NOT use for the normal attended pipeline (use the specflo-brainstorm/spec/plan/execute skills), or when the user wants to approve each boundary.
Installs into .claude/skills of the current project.
Are you the author of Specflo Auto?
Add the live security badge to your README. It updates with every re-scan.
[](https://www.skillsdirectory.com/skills/tacotakumi-specflo-auto)
---
name: specflo-auto
description: Use when the user wants an unattended specflo run — "auto mode", "autopilot", "run it on its own", "keep going without me", "don't stop to ask" — map that to `specflo auto`. It is an explicit, per-invocation opt-in that drives the pipeline across phase boundaries without the ask-first pause. Do NOT use for the normal attended pipeline (use the specflo-brainstorm/spec/plan/execute skills), or when the user wants to approve each boundary.
---
# auto
Turn a user's **unattended-run** intent into a `specflo auto` invocation, then
follow the payload it emits. `specflo auto` is the explicit, per-invocation opt-in
that runs the specflo pipeline (`brainstorm → spec → plan → execute`) from the
current phase toward completion **without** the ask-first confirmation pause. The
CLI does all the heavy lifting — it emits a self-contained payload carrying the
full autonomy policy, the guardrail stop-conditions, the verbatim checkpoint, and
the next step; this skill only recognises the intent, runs the command, and hands
the emitted directives back to the loop. **It reimplements none of that logic** —
the emitted bootstrap is the source of truth, not this file.
## When to use
- The user opts into an unattended run: "auto mode", "autopilot", "run it on its
own", "keep going without stopping to ask", "don't pause at each phase".
→ `specflo auto`.
## When NOT to use
- The normal **attended** pipeline, where the user approves each phase boundary —
use the `specflo-brainstorm` / `specflo-spec` / `specflo-plan` / `specflo-execute` skills, which pause and wait.
- The user wants to review or approve before crossing a boundary — that is the
default; do not switch to auto for them.
## Process
1. **Run the command.** `specflo auto` (add `--autonomy …`, `--max-passes …` as
the user asks; see below). specflo only *prints* a payload — it drives no loop,
spawns no nested agent, and never clears context.
2. **Follow the emitted payload, verbatim.** It has three parts: the **auto-mode
bootstrap** (marked `== specflo auto-mode bootstrap ==`) carrying the autonomy
policy and every guardrail stop-condition; the **verbatim checkpoint**
(read-first files, next action, any milestone beat); and the generated
**next-step block** (marked `== specflo next step ==`) naming the current phase
and its immediate next action. Obey the bootstrap's directives as written — do
not paraphrase, second-guess, or relax them.
3. **Do the phase work under the bootstrap.** The next-step block points at the
phase skill (`specflo-brainstorm` / `specflo-spec` / `specflo-plan` / `specflo-execute`) for the current phase —
carry the phase work with it, but under the bootstrap's **boundary override**:
once a phase validates, advance and keep going instead of pausing.
4. **The outer harness owns the loop, not specflo.** The seamless
clear-context-and-continue trigger is the harness's job (e.g. a SessionStart
hook / clearanddo / pi). Each continuing pass re-runs `specflo auto` — the
bootstrap self-propagates, so the run stays in auto mode across a context clear
rather than reverting to ask-first.
5. **Run and record the review round.** At the end of execute the run performs
the final whole-branch review itself — in fresh context, per the execute skill,
never as inline self-review — and records it with `specflo review start` and
`specflo review done`. Completing the project is not part of that:
the run halts on the completion directive and `specflo advance` stays the
user's call, which is where auto already stopped. When the latest round asks
for changes and the level has used its round budget, the pass stops with the
`review-budget` reason: one more round (`specflo review start --over-budget`)
or a waive (`specflo review waive --reason <why>`) is the user's call.
**Ladder run exception** (`specflo auto --ladder`): the run advances each
level itself. At quick, fast and full, run `specflo advance` once the level's
work and review are done: it ends only that level, not the run. Then run
`specflo auto` again; that pass cuts the next level's branch, or at full
closes the ladder. The payload's ladder clause says this on every pass. At
the round budget a ladder waives the level's review itself and goes on; its
row shows `waived (budget)` with the open items. The
ladder never merges, pushes or deletes a branch: picking a branch stays the
user's call.
6. **Stop when the payload says stop.** When `specflo auto` emits an escalation,
the kill-switch halt, or the completion directive (rather than a bootstrap),
the run is over — hand off to the human; do not start another pass.
## Flags (surface only — semantics live in the CLI)
Pass these through as the user requests; for their exact behaviour and defaults,
defer to `specflo auto --help` and the emitted bootstrap — this skill does not
restate them:
- `--autonomy {safe,autonomous,yolo}` — how far the run goes unattended (default
`safe`), with a matching config default.
- `--max-passes N` — the runaway pass cap; on reaching it the run escalates to the
human instead of continuing.
- `--off` / `--on` — set or clear the durable auto-off kill switch for the active
project.
- `--ladder` — on a quick project, start one run that climbs quick, fast and
full on stacked local branches and writes `ladder.md` (see the ladder run
exception in step 5). Later passes are plain `specflo auto`.
## Notes
- `specflo auto` is **strictly additive**: the default attended `hook reseed` /
`specflo checkpoint` pause is unchanged. Auto is a separate surface the user
opts into per invocation — there is no persisted "auto on" default.
- specflo **owns the payload, never the trigger**: it emits harness-neutral plain
text and leaves the clear-and-continue to whatever harness is driving.
## Verification
- `specflo auto` at the active project prints the three-part payload (the
`== specflo auto-mode bootstrap ==` and `== specflo next step ==` markers, with
the verbatim checkpoint between them) and exits 0.
- On a complete project, or when a guardrail trips, it prints a stop/escalation
directive (no bootstrap) instead — the signal to hand off.