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 skills add alexei-led/cc-thingz --skill spec-flowgit clone --depth 1 https://github.com/alexei-led/cc-thingzWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/alexei-led/cc-thingz/spec-flow)<a href="https://agentmods.dev/skills/alexei-led/cc-thingz/spec-flow"><img src="https://agentmods.dev/badge/skills/alexei-led/cc-thingz/spec-flow/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/alexei-led/cc-thingz/spec-flow"><img src="https://agentmods.dev/badge/skills/alexei-led/cc-thingz/spec-flow.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector pass
What 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.1 | $0.00071 | $0.01087 |
| Opus 5.5 | $0.00028 | $0.00435 |
| Sonnet 5.5 | $0.00014 | $0.00217 |
| Haiku 4.5 | $0.00007 | $0.00109 |
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 27d 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 — 119 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Spec flow
Lightweight loop for controlled work, one task at a time: plan one slice, execute one task, checkpoint or close, repeat.
scripts/specctl (written specctl below) owns state. Do not edit task status
or .spec/SESSION.yaml by hand. references/specctl-commands.md lists every command.
references/method.md covers task quality, templates, the planning output, and
the mini-interview.
State model
.spec/tasks/TASK-*.md— executable vertical slices. Required for work..spec/epics/EPIC-*.md— optional group for multi-task plans..spec/reqs/REQ-*.md— optional WHY/WHAT context for ambiguous work..spec/SESSION.yaml— active task, step, base commit..spec/PROGRESS.md— append-only activity log.
Task states: todo, in-progress, done.
Modes
Orient
For status, the next task, resume, or health: run specctl status, ready,
session handoff, and validate. Report the active session, the next ready task,
validation issues, and the smallest next action.
Plan
For an idea, requirement, bug, or project gap that needs an executable plan.
Done when the smallest useful artifact set exists and passes specctl validate,
and its first task appears in specctl ready (a REQ-only plan has no ready task
yet). Create tasks and requirements with specctl new task|req, then fill in
the details; write an EPIC-* file by hand. Pick the smallest set:
- one clear slice: one
TASK-* - several slices: one
EPIC-*plus tasks - unclear WHY or WHAT: one
REQ-*first
Run specctl init when .spec/ is missing, and check status and session before
changing files. In an existing project, read the code and project instructions
first, and link REQ or EPIC context only when it reduces ambiguity. Ask
questions only when the slice is unclear. Show the proposed plan before writing it
unless the user already authorized that scope. Build a full backlog only on
request, and keep implementation code out of plan files.
Execute
For work, continue, or implement. Done when the relevant build/test/lint checks
pass on what you changed, or you name each check that did not run and why. Before
closing, confirm the acceptance criteria and show the scoped diff or
specctl session handoff; if the task cannot finish, checkpoint it instead.
What ships with it
5 files beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
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.
- 27d ago Changed · -42 lines 0eb10cacc361
- 1mo ago Changed d6bf82f1273d
- 1mo ago First seen · 161 lines · 71 tokens per session scan A 10f71a7d744d
spec-flow is a skill published in the GitHub repository alexei-led/cc-thingz (38 stars, last pushed today), licensed MIT. It adds 71 tokens to every session and 1,087 once invoked, about $0.0003 per session on Opus 5.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-30.
Other skills, from other repositories
issue-creation
Trigger: issue creation, bug reports, feature requests, or issue approval. Create and triage GitHub issues from repository evidence.
systemic-issue-triage
Trigger: new issue, bug report, triage, backlog, issue flood, community report, root cause, dead-end, blocked user. Attack issues by root class, never one-by-one; fixes must shrink the system, not grow it.
ring:dispatching-workflows
Executing a phased plan in rolling waves where each phase runs as one multi-agent workflow harness: the supervisor elaborates the phase into tasks against the real landed code, launches a workflow that implements with TDD and runs mandatory in-harness review plus an adversarial contrarian pass (and researchers when…
ring:implementing-tasks
Implementing a single planned task (Task N.M.T) end-to-end: selects the right backend agent by language and service type, drives one TDD RED->GREEN turn, then verifies coverage, lint, license headers, runtime, and delivery before handoff. Runs as Gate 0 before ring:reviewing-code. Use to drive ONE task inside an…
ring:managing-dev-cycle
Managing an in-progress development cycle without driving it: status reports phase, epic/gate progress, assertiveness, and elapsed time from current-cycle.json; cancel confirms, marks the cycle cancelled, and writes a partial feedback report. Use when checking the status of, or cancelling, a running dev cycle. Skip…
ring:mapping-feature-relationships
Mapping how features relate and phasing the work: categorizing PRD features, grouping them into domains, charting cross-feature journeys, dependencies, and integration points, and defining the binding Phases that plan.md mirrors one-to-one at Gate 7. Gate 2 of ring:planning-large-features; runs after…