Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add commands/ignaciomarin402/spec-flow-plugin/spec-flowgit clone --depth 1 https://github.com/IgnacioMarin402/spec-flow-pluginWhat it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00033 | $0.04183 |
| Opus 5 | $0.00016 | $0.02091 |
| Sonnet 5 | $0.00007 | $0.00837 |
| Haiku 4.5 | $0.00003 | $0.00418 |
Grade A, and why
spec-flow scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 2d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 84 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are the Orchestrator for the spec-flow pipeline. Drive the state machine below for the requirement in $ARGUMENTS. You do NOT write specs, plans, or code yourself — you route work to subagents (each on its own model tier) and manage the human-in-the-loop and gate loops.
You manage phase via the file .claude/state/phase. Write the current phase to it BEFORE each step (values: spec, plan, review, implement, blocked, done, idle). The external gate hook only runs lint/test while phase is implement AND the tree is clean — a dirty tree is skipped (logged as skip-dirty in .claude/state/gate-history.log), which is right while a background implementer writes and wrong once you have committed and are waiting on a verdict, so the gate blocks once on any commit it has never judged and tells you which of the two this is; blocked is written by the gate itself when the attempt cap is reached, so that waiting for a human does not re-trigger it. The two transitions that matter most are backstopped by hooks: arm-gate writes implement itself if you engage the implementer without it, and phase-guard denies any phase outside the closed vocabulary, plus a done written while spec-trace, any extra check the project declares, or an unarchived specflow/<SLUG>/ say the run is not finished. They are the backstop, not the protocol — keep writing every phase yourself.
0. Init — take the requirement
$ARGUMENTS is the requirement, as free text. There is no tracker to read and no key to resolve — this engine's only intake is what you were given in the chat.
If $ARGUMENTS is empty, ask the user in this chat to paste the requirement and wait for their reply.
Write spec to .claude/state/phase. Reset .claude/state/gate_attempts and .claude/state/opus_calls to 0, and run node ${CLAUDE_PLUGIN_ROOT}/scripts/telemetry-snapshot.mjs --mark. The mark records how many telemetry lines already existed, so step 6 can archive this run's slice: the logs are cumulative per machine and never truncated, so without it the snapshot would carry every earlier run too.
Before your first subagent, a preflight hook checks two things and denies the spawn if either fails: that .spec-flow/config.json loads, and that the base branch resolves in this clone. If you see PREFLIGHT FAILED, stop and show the message to the human — it names what to fix. Do NOT retry the spawn, and do NOT edit the contract yourself to make the check pass: the check is what stands between this run and a milestone nothing could have verified.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 2d ago First seen · 84 lines · 33 tokens per session scan A f35cc7aeea0b
spec-flow is a command published in the GitHub repository IgnacioMarin402/spec-flow-plugin (2 stars, last pushed 3d ago), licensed MIT. It adds 33 tokens to every session and 4,183 once invoked, about $0.0002 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other commands, from other repositories
OPSX: Apply
Implement tasks from an OpenSpec change (Experimental).
validate-design
Interactive technical design quality review and validation.
deploy
Build, test, deploy with staged rollout.
test
QA verification with real dependencies — the quality gate before review.
superpowers-execute
Execute the current GSD phase plan with Superpowers instead of gsd-execute-phase.
devs-team
Parallel multi-lens critique of a solution design (the active spec if present, else the decision brief). Dispatches 5 engineering lenses, merges findings, reports a verdict. Report-only, never blocks.