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 PrabhdeepSingh/claude-plugins --skill tddgit clone --depth 1 https://github.com/PrabhdeepSingh/claude-pluginsWrote 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/prabhdeepsingh/claude-plugins/tdd)<a href="https://agentmods.dev/skills/prabhdeepsingh/claude-plugins/tdd"><img src="https://agentmods.dev/badge/skills/prabhdeepsingh/claude-plugins/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/prabhdeepsingh/claude-plugins/tdd"><img src="https://agentmods.dev/badge/skills/prabhdeepsingh/claude-plugins/tdd.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.00080 | $0.04884 |
| Opus 5.5 | $0.00032 | $0.01954 |
| Sonnet 5.5 | $0.00016 | $0.00977 |
| Haiku 4.5 | $0.00008 | $0.00488 |
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 — 177 lines — stays where its author put it; the contents beside it link to each section on GitHub.
TDD — test-first, every time
Tests aren't something you write when the feature is done. They're the tool you use to design the feature. A test written before the code is a precise, executable specification; a test written after is just an assertion that you didn't introduce new bugs today. Code written test-first is more focused, more decoupled, and easier to maintain than code written any other way — the test forces you to think about the interface before the implementation, and that pressure is the real payoff.
Follow these rules the same way you follow [[code-standards]] — as the instincts of someone who's maintained production code for two decades, not as bureaucracy.
How to apply this
Before writing a single line of production code, write the failing test. Let the test drive the design. Then write the minimum code to make it pass. Then refactor. That's the loop — run it in small increments, constantly, for every behavior you add.
Discover the stack before the first red — the loop is universal; the commands are not. Find the build system from its manifest (package.json, pyproject.toml, go.mod, Cargo.toml, pom.xml, Gemfile, a Makefile); prefer checked-in wrappers (./gradlew, ./mvnw, make test, a repo script) over globally installed tools; learn both the focused-single-test command (run during the loop) and the full-suite command (run before completion) — they differ in every framework; and read the README/CONTRIBUTING and CI workflow files, because those show the commands that actually gate merges. Never assume a default like npm test — a wrong guess reads as "no tests exist" and derails the whole loop.
Invoked directly as /sonu:tdd: apply the loop to $ARGUMENTS — the text typed after the invocation; if that token appears literally or is empty, apply it to the current change in context. This produces test and implementation files in the working tree, not a printed plan. If the codebase's test structure is unclear, read the existing tests first to establish conventions before adding new ones. For the full design → build → hand-off lifecycle, run /sonu:build instead — it runs this same methodology as its build phase and adds the design gate before and the self-review after.
What ships with it
1 file 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 Changed · +20 lines a809bb1a4a25
- 1mo ago First seen · 157 lines · 80 tokens per session scan A 5299324b38f3
tdd is a skill published in the GitHub repository PrabhdeepSingh/claude-plugins (4 stars, last pushed 1mo ago), licensed MIT. It adds 80 tokens to every session and 4,884 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-31.
Other skills, from other repositories
tdd-with-pest
Apply RED-GREEN-REFACTOR with Pest v4 (PHP 8.3+) for Symfony via the PHPUnit bridge; Foundry factories, WebTestCase, verify failures first.
tdd-with-phpunit
Apply RED-GREEN-REFACTOR with PHPUnit 10/11 for Symfony; KernelTestCase/WebTestCase, attributes (#[Test]/#[DataProvider]), Foundry.
test-audit
Audit test suites for T1-T4 violations using AST analysis, mock detection, and multi-stage synthesis. Invoke when user asks to audit tests, check test quality, find mock violations, review test effectiveness, or inspect test suites for over-mocking. Triggers automatic rewrites when quality gates fail.
ccc-e2e
Pre-release assessment that fans out via $ccc-fleet into up to three isolated workers (QA audit, unit tests, Playwright E2E) running $ccc-testing lanes, then writes a severity-ranked PASS or FAIL verdict. Use when about to tag a release, after a large merge, or asking is this ready.
unity-tests-write
Use when writing Unity tests, including EditMode tests, PlayMode tests, performance testing, and code coverage.
mutation-campaign-configuration
Use when the user mentions mewt, muton, or mutation testing and asks to initialize, scope, estimate, configure, validate, or optimize a campaign before execution. Writes only the TOML config and validates readiness without generating mutants or touching source. Not for running the campaign: use mewt run separately.