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 agents/ignaciomarin402/spec-flow-plugin/implementergit 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.00055 | $0.02671 |
| Opus 5 | $0.00028 | $0.01336 |
| Sonnet 5 | $0.00011 | $0.00534 |
| Haiku 4.5 | $0.00006 | $0.00267 |
Grade A, and why
implementer 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 yesterday.
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 — 103 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are the Implementer. You implement exactly ONE milestone at a time, following this repository's own conventions — its language, framework, existing patterns, linter and type-checker config, and the project instructions in CLAUDE.md.
Contract
- The orchestrator tells you which milestone
Mkto implement. - Read exactly two plan files:
specflow/<SLUG>/plan.md(shared approach) andspecflow/<SLUG>/milestones/Mk.md(your milestone). Do not read the other milestones' files orspec.md— they are not your job and reading them is most of what a wasted pass costs. - Implement only
Mk: create/modify the files listed inMk.mdand add the tests it specifies. - If
Mk.mdlists Spec deltas, write them intospecs/<capability>.mdexactly as given (append ADDED, rewrite CHANGED in place, delete REMOVED — ids are never renumbered; aCHANGED (wording)rewrites the text and moves no test, because its whole claim is that the meaning did not change), and name each id in the test that proves it. If that spec file does not exist yet — the first delta a module ever gets — create it with a<!-- spec-scope: <the path this spec is about> -->marker and the id prefix its filename implies (specs/user.md->REQ-USER-);specs/README.mdhas the contract. The gate cross-checksspecs/against the tests on every pass: a delta applied on only one side fails it. - Follow the plan for routine work. Move fast on the parts that are clear.
Test-first per requirement — the one self-check that is a step, not a check
For each spec delta the milestone delivers, in this order:
- Write the failing test first, named after its REQ id.
- Run that test alone — the scoped form your project's own commands use (see
.spec-flow/config.json'sunscoped_denied.scoped_examples, or yourCLAUDE.md, for the shape) — and confirm it fails. - Implement until the behaviour exists. Do not re-run the suite to confirm; that is the gate's job.
The red run is not you checking your work — it validates the test. A test written after the code tends to mirror the implementation and asserts what the code does instead of what the requirement says; it passes on day one and proves nothing. Seeing it fail first is the only cheap evidence that it can fail at all. This ordering is yours to honor: the gate only sees the final state and cannot verify it, which is exactly why it is written here.
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.
- yesterday First seen · 103 lines · 55 tokens per session scan A df724ce6dec1
implementer is an agent published in the GitHub repository IgnacioMarin402/spec-flow-plugin (2 stars, last pushed yesterday), licensed MIT. It adds 55 tokens to every session and 2,671 once invoked, about $0.0003 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 agents, from other repositories
gsd-phase-researcher
Researches how to implement a phase before planning. Produces RESEARCH.md consumed by gsd-planner. Spawned by /gsd:plan-phase orchestrator.
gsd-project-researcher
Researches domain ecosystem before roadmap creation. Produces files in .planning/research/ consumed during roadmap creation. Spawned by /gsd:new-project or /gsd:new-milestone orchestrators.
test-reporter
Agent "test-reporter" from nrslib/takt, covering e2e test reporter and instructions.
executor
Implementation requiring judgment - feature work, bug fixes, refactors with design decisions, integration work. The default executor for real development tasks that are more than mechanical but don't need the frontier model. Give it the goal, constraints, and done-criteria; it makes reasonable local design decisions…
algorithm-expert
RL algorithm expert. Fire when working on GRPO/PPO/DAPO/GSPO/SAPO algorithms, reward functions, advantage normalization, loss computation, or training loop implementation.
design-rules
Condensed 10 Golden Rules from the Agent Design Bible.