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 arrrrny/zuraffa --skill speckit-tdd-plangit clone --depth 1 https://github.com/arrrrny/zuraffaWrote 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/arrrrny/zuraffa/speckit-tdd-plan)<a href="https://agentmods.dev/skills/arrrrny/zuraffa/speckit-tdd-plan"><img src="https://agentmods.dev/badge/skills/arrrrny/zuraffa/speckit-tdd-plan/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/arrrrny/zuraffa/speckit-tdd-plan"><img src="https://agentmods.dev/badge/skills/arrrrny/zuraffa/speckit-tdd-plan.svg" alt="Reviewed on agentmods" width="80" height="20"></a>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.00044 | $0.00843 |
| Opus 5 | $0.00022 | $0.00421 |
| Sonnet 5 | $0.00009 | $0.00169 |
| Haiku 4.5 | $0.00004 | $0.00084 |
Grade A, and why
speckit-tdd-plan 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 7d 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 — 89 lines — stays where its author put it; the contents beside it link to each section on GitHub.
TDD Plan (zfa-delegating)
Turn this feature's specification into a test list. When this project is
zuraffa-wired, derivation is deterministic — dispatch to zfa tdd plan.
The LLM never re-derives what zfa already derives.
User Input
$ARGUMENTS
Step 0 — Engine detection
Check whether zfa can drive this project:
zfa --version 2>/dev/null && test -f .zfa.json && echo "ZFA_OK" || echo "ZFA_MISSING"
ZFA_OK→ Step 1 (deterministic dispatch)ZFA_MISSING→ this project is not zuraffa-wired; fall back to the LLM-guided derivation in "Fallback Path" below.
Step 1 — Resolve the feature
Follow the standard feature resolution:
- Feature directory from input argument, or
.specify/feature.json→feature_directory, orcheck-prerequisites.sh --json --paths-only
Set FEATURE_SLUG to the resolved directory name (e.g. 003-user-auth).
Write it to .specify/feature.json if not already pinned.
Step 2 — Dispatch to zfa
zfa tdd plan "$FEATURE_SLUG" 2>&1
Interpret the exit code:
| Exit | Meaning | Action |
|---|---|---|
| 0 | Plan written | Read the emitted test-list, report counts, proceed to tasks.md sync (Step 3) |
| 1 | Derivation stopped honestly (gap found) | Report the gap verbatim; do NOT paper over it |
| 2 | Grammar/parse error in the spec | Report the offending line; suggest spec fix |
| 3 | Template version drift | Report the fix line; suggest extension install/upgrade |
| other | Runner error | Report verbatim; do not retry blindly |
Step 3 — Sync tasks.md
After zfa emits the test list, update tasks.md so every behavior has its
test task before its implementation task, and mark test tasks mandatory.
This is bookkeeping around zfa's output — the LLM does this part:
- Read
FEATURE_DIR/tdd/test-list.md(zfa's output). - For each PENDING behavior, ensure a task exists in
tasks.mdwith a[behavior: <id>]marker; insert before the corresponding implementation task if missing. - Mark behavior tasks as mandatory (never skippable).
- Preserve existing task ids, checkbox states, and format.
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.
- 7d ago Changed · +88 lines · +44 tokens per session 056c8c004ab2
- 8d ago Changed · -272 lines · -58 tokens per session 6178f92569a3
- 12d ago First seen · 273 lines · 58 tokens per session scan A 926d4ad39b27
speckit-tdd-plan is a skill published in the GitHub repository arrrrny/zuraffa (5 stars, last pushed today), licensed MIT. It adds 44 tokens to every session and 843 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 skills, from other repositories
compose:tdd
Use when implementing any feature or bugfix, before writing implementation code.
skillshare-implement-feature
Implement a feature from a spec file or description using TDD workflow. Use this skill whenever the user asks to: add a new CLI command, implement a feature from a spec, build new functionality, add a flag, create a new internal package, or write Go code for skillshare. This skill enforces test-first development…
implement-feature
Implement an approved feature plan with fresh-context slices, TDD, evidence, and PR-ready output.
common-tdd
Guides quality-first TDD for new behavior, bug fixes, and test changes. Selects the smallest test layer, proves a distinct regression risk, and runs bounded RED-GREEN-REFACTOR verification.
tdd-cycle
Execute full TDD red-green-refactor cycle with validation gates. Use when saying "TDD cycle", "test-driven development", or "full TDD workflow".
implement
Implement a technical design by decomposing it into dependency-ordered vertical slices, executing each with TDD red-green, reviewing each via an isolated sub-agent, and persisting progress to a state file so work survives session restarts. Use when the user has a tech design (doc or settled conversation) and says…