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 tsai09495/matt-pocock-engineering --skill tddgit clone --depth 1 https://github.com/tsai09495/matt-pocock-engineeringWrote 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/tsai09495/matt-pocock-engineering/tdd)<a href="https://agentmods.dev/skills/tsai09495/matt-pocock-engineering/tdd"><img src="https://agentmods.dev/badge/skills/tsai09495/matt-pocock-engineering/tdd.svg" alt="Measured on agentmods" 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.00038 | $0.00591 |
| Opus 5 | $0.00019 | $0.00296 |
| Sonnet 5 | $0.00008 | $0.00118 |
| Haiku 4.5 | $0.00004 | $0.00059 |
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 8d 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 — 59 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Test-Driven Development
TDD is a hard RED → GREEN feedback loop that produces tests worth keeping. Read quality-baseline.md, tests.md, and mocking.md.
Use the project's domain glossary and relevant ADRs so test names and behavior match established language. Use codebase-design as the single source for module depth, interface, and seam vocabulary.
Choose the behavior and seam
Select one observable behavior and the highest practical public seam that exercises it. Tests should use the same interface as real callers, not private methods or implementation-only side channels.
- Reuse an obvious established seam without repeated confirmation.
- Explain and confirm a new, ambiguous, or expensive seam before adding it.
- If no correct seam can exercise the behavior, report the architecture limitation rather than adding a misleading shallow test.
One vertical cycle
RED
- Write one focused behavior test.
- Derive expected values from the requirement, a worked example, protocol/specification, trusted fixture, or independent calculation.
- Run the focused test.
- Confirm it fails for the expected missing or broken behavior—not a syntax, fixture, or environment mistake.
GREEN
- Make the smallest production change that satisfies the test.
- Run the focused test and confirm it passes.
- Run nearby affected tests or checks to catch collateral breakage.
Only then choose the next behavior and repeat.
GREEN micro-refactor
While tests remain GREEN, make small local improvements needed for immediate readability or duplication. Rerun affected tests after each material step. Do not fold a systematic redesign, broad cleanup, or speculative abstraction into the loop; surface it during code-review or as a separate architecture task.
Anti-patterns
- Horizontal slicing: writing all tests and then all implementation.
- Implementation coupling: mocking internal collaborators, testing private methods, or asserting call choreography instead of behavior.
- Tautology: deriving the expected value with the same algorithm or source as the implementation.
- False RED: a test fails because setup is broken rather than because the behavior is missing.
- Speculation: adding hooks or generalized interfaces for imagined future tests.
- Over-mocking: mock only true system boundaries such as external services, time, randomness, or expensive infrastructure when a real adapter is impractical.
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.
- 8d ago First seen · 59 lines · 38 tokens per session scan A 005163799bb9
tdd is a skill published in the GitHub repository tsai09495/matt-pocock-engineering (2 stars, last pushed 14d ago), licensed MIT. It adds 38 tokens to every session and 591 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
nl-to-constraints
Transforms natural language requirements (user stories, verbal descriptions, business rules) into formal specifications and constraints. Use when converting informal requirements into structured, testable specifications with explicit constraints. Outputs in multiple formats including BDD-style Given-When-Then, JSON…
lsp-refactoring
Intelligent code refactoring using IDE-level tools (rename, find-references, go-to-definition), AST-aware pattern matching, and TDD verification. Use for safe, large-scale refactoring with precision.
execute
Dispatch and execute implementation plans with TDD and checkpoints. Use when plan is ready. Parallel by default for independent tasks.
tdd
Strict test-driven development for behavior changes. Requires verified RED before production code, minimal GREEN, and refactor only after passing tests.
tdd-workflow
Test-Driven Development workflow for implementing features with tests first; enforces the two-commit audit trail (failing-test commit, then green commit) and shows-your-work verification for agent-driven work.
tests-purge-unneeded
Delete tests that don't catch real bugs — the inverse of TDD. Use when reviewing legacy test suites, slow CI investigations, refactor-driven test sweeps, or evaluating whether a test the type system already covers should stay. Thesis — a test exists only if removing it would let a real bug reach production.