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 fusengine/agents --skill tddgit clone --depth 1 https://github.com/fusengine/agentsWrote 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/fusengine/agents/tdd)<a href="https://agentmods.dev/skills/fusengine/agents/tdd"><img src="https://agentmods.dev/badge/skills/fusengine/agents/tdd/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/fusengine/agents/tdd"><img src="https://agentmods.dev/badge/skills/fusengine/agents/tdd.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector warn
SkillSpector: 1 finding, up to medium
These are SkillSpector’s own severities. On a checked sample its high-severity flags on skills were ~96% false positives — a documented command, a public API, a “never do X” rule — so we show them as a caution to read, not a verdict. Why →
- medium MCP Rug Pull · line 64 npx commands without a version suffix (e.g. @1.0.0) create a rug-pull risk if the upstream server is compromised and publishes a malicious update.Fix: Pin the version: npx @scope/[email protected]
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.00033 | $0.00726 |
| Opus 5.5 | $0.00013 | $0.00290 |
| Sonnet 5.5 | $0.00007 | $0.00145 |
| Haiku 4.5 | $0.00003 | $0.00073 |
Grade A, and why
tdd 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 1mo 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 — 81 lines — stays where its author put it; the contents beside it link to each section on GitHub.
It never skips a VERIFY step -- a test that passes on first run proves nothing and must be investigated, not accepted.
TDD Skill
Write the test first. Watch it fail. Write minimal code to pass.
The Iron Law
No production code without a failing test first.
Every line of production code must be justified by a test that failed without it. No exceptions. No shortcuts. No "I'll test after."
Agent Workflow
1. DETECT -> Identify stack, test framework, existing test patterns
2. RED -> Write ONE failing test for the next behavior
3. VERIFY -> Run test, confirm it fails for the EXPECTED reason
IF the test fails for a DIFFERENT reason (syntax error, wrong import, missing fixture) → fix the test itself and re-run. Do NOT proceed to GREEN until the failure matches the intended behavior.
4. GREEN -> Write the SIMPLEST code that makes the test pass
5. VERIFY -> Run tests, confirm ALL pass (new + existing)
6. REFACTOR -> Clean up while keeping all tests green
7. REPEAT -> Next behavior = next failing test
CRITICAL: Never skip VERIFY steps. A test that passes on first run proves nothing.
RED-GREEN-REFACTOR Cycle
See references/red-green-refactor.md for the detailed cycle with rules and verification steps.
Reference Guide
| Topic | Reference |
|---|---|
| Full RED-GREEN-REFACTOR cycle | red-green-refactor.md |
| Common mistakes and red flags | anti-patterns.md |
| Per-stack test commands | stack-commands.md |
What ships with it
3 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.
- 1mo ago First seen · 81 lines · 33 tokens per session scan A 9868b22627b6
tdd is a skill published in the GitHub repository fusengine/agents (31 stars, last pushed 4d ago), licensed MIT. It adds 33 tokens to every session and 726 once invoked, about $0.0001 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
test-driven-development
Enforces the red-green-refactor TDD cycle. No production code without a failing test first. Use when implementing features, fixing bugs, or writing production code.
feature-dev
Take one new feature slice from idea to reviewed, committed code in a single guided pass — scope it into the smallest shippable slice, build it test-first with strict TDD, review and fix the diff, then commit it. Chains slice → test-driven-development → the built-in /code-review → git-commit. Not for reviewing an…
test-driven-development
Strict red-green-refactor TDD workflow for implementing features, fixing bugs, or changing behavior in Rails applications. Enforces the discipline of writing a failing test before any production code. Use whenever you want to implement with TDD — whether a new feature, a bugfix, a refactor, or any behavior change.
evaluating-as-user
Evaluates software quality from an end user's perspective. Use when emulating a real user to assess a running web app, CLI tool, or API.
verifying-work
Gates completion claims with mandatory evidence — no "should work" or "probably passes" without fresh verification output. Use when verifying test results, confirming builds pass, checking linter output, or validating acceptance criteria.
symfony-testing
Testing Symfony hexagonal architecture with PHPUnit 10-13 and PHPStan 2: test organization mirroring src/, pure domain unit tests, handler tests with in-memory adapters and stubs, functional API tests, Messenger in-memory transport, Foundry 2 factories, TDD workflow. Use when: test, PHPUnit, TDD, unit test…