Skip to content
Back to skills

Specflo Auto

ASecurity

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.

  • 9 stars
  • 0 votes
  • 0 copies
  • 3 views
  • Added September 3, 2026
ai-agentsgo

Works with

  • cli

Security analysis

A100/100

Scanned September 29, 2026

npx -y skills add TacoTakumi/specflo --skill specflo-auto --agent claude-code

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.

Security grade badge for Specflo Auto
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/tacotakumi-specflo-auto/badge)](https://www.skillsdirectory.com/skills/tacotakumi-specflo-auto)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
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.

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…

Newsletter

Get the weekly list of safe new skills, and the ones we pulled.