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 skills/juanmhidalgo/claude-plugins/tdd-patternsnpx skills add juanmhidalgo/claude-plugins --skill tdd-patternsgit clone --depth 1 https://github.com/juanmhidalgo/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/juanmhidalgo/claude-plugins/tdd-patterns)<a href="https://agentmods.dev/skills/juanmhidalgo/claude-plugins/tdd-patterns"><img src="https://agentmods.dev/badge/skills/juanmhidalgo/claude-plugins/tdd-patterns.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 | $0.00035 | $0.00937 |
| Opus 5 | $0.00017 | $0.00468 |
| Sonnet 5 | $0.00007 | $0.00187 |
| Haiku 4.5 | $0.00003 | $0.00094 |
Grade A, and why
tdd-patterns 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 — 75 lines — stays where its author put it; the contents beside it link to each section on GitHub.
TDD Cycle Constraints
Iteration Limits
- Maximum 5 RED-GREEN cycles per feature. If tests still fail after 5 cycles, STOP and report the blocking issue to the user.
- Stuck-after-3 rule: If the same test failure persists after 3 consecutive cycles with different fix attempts, STOP immediately. Do not keep trying the same approach.
Phase Ordering
Phases are strictly sequential. Never skip or reorder:
- RED: Write tests that MUST fail. If any test passes immediately, it is testing existing behavior — remove or rewrite it.
- GREEN: Write the minimum code to make tests pass. No refactoring, no optimization, no "while I'm here" changes.
- REFACTOR: Only after all tests are green. Run tests after every refactoring change. If a test breaks during refactor, undo the refactoring change.
Fix Implementation, Not Tests
When a test fails during the GREEN phase:
- Default action: fix the implementation, not the test.
- Only modify a test if the test itself has a bug (wrong assertion, incorrect setup) — never weaken a test to make it pass.
- If the spec is ambiguous, ask the user rather than adjusting the test.
Coverage Gate Workflow
Check Changed Files Only
- Run coverage on the full test suite but report coverage for changed/new files only.
- Use the project's configured coverage tool and thresholds first.
- If no coverage configuration exists, apply 80% line coverage minimum on changed files.
Below-Threshold Response
- Identify specific uncovered lines (not just percentages).
- Write tests for meaningful uncovered paths — skip trivial getters/setters and
__str__methods. - Re-run coverage after adding tests. Maximum 2 additional coverage cycles.
Lint and Format Detection
Detect the project's lint/format tools in this order:
- Check
package.jsonscripts forlint/formatkeys. - Check for config files:
pyproject.toml(ruff/black),.eslintrc*,prettier.config*,rustfmt.toml,.golangci.yml. - Check
Makefile/justfilefor lint/format targets. - If no tool found, skip lint phase with a note — do not install tools.
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 · 75 lines · 35 tokens per session scan A 9fd7ecfc80c3
tdd-patterns is a skill published in the GitHub repository juanmhidalgo/claude-plugins (8 stars, last pushed 10d ago), licensed MIT. It adds 35 tokens to every session and 937 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-09-03.
Other skills, from other repositories
rtk-tdd
Enforces TDD (Red-Green-Refactor) for Rust development. Auto-triggers on implementation, testing, refactoring, and bug fixing tasks. Provides Rust-idiomatic testing patterns with anyhow/thiserror, cfg(test), and Arrange-Act-Assert workflow.
software-test-execution
Run scoped tests for a TDD slice, determine the appropriate test framework and command, and report structured pass/fail results. Use when tests need to be executed after writing, implementing, or refactoring code. Reads test metadata, discovers the test framework if needed, executes the scoped test command, parses…
software-code-refactoring
Improve production code quality while preserving all existing test behavior. Commonly used for the Refactor phase of TDD red-green-refactor, but applicable to any codebase with tests. Use when production code works but needs cleanup — reducing duplication, improving naming, simplifying complexity, aligning with…
software-test-creation
Write failing tests for a TDD slice based on acceptance criteria and codebase conventions. Use when the "red" phase of red-green-refactor requires tests that define expected behavior before implementation exists. Discovers codebase test conventions first, writes test files that compile or parse but fail because the…
software-implementation
Write the minimal production code needed to make failing TDD tests pass (Green phase of red-green-refactor). Use when failing tests exist and production code must be written or modified to satisfy them. Reads and interprets failing test output, discovers codebase conventions (module layout, naming, import patterns…
tdd-workflow
Drive implementation through a test-first loop: write a failing test, make it pass with the simplest change, then refactor under a green suite. Use when the user asks for TDD or test-driven development, wants tests written before the code, is adding behaviour to code that has tests, is fixing a bug and wants a…