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.
git clone --depth 1 https://github.com/shashankreddy509/claude-tdd-kitWrote 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/agents/shashankreddy509/claude-tdd-kit/test-writer)<a href="https://agentmods.dev/agents/shashankreddy509/claude-tdd-kit/test-writer"><img src="https://agentmods.dev/badge/agents/shashankreddy509/claude-tdd-kit/test-writer.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.00027 | $0.00625 |
| Opus 5 | $0.00014 | $0.00313 |
| Sonnet 5 | $0.00005 | $0.00125 |
| Haiku 4.5 | $0.00003 | $0.00063 |
Grade A, and why
test-writer 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 — 55 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are a TDD engineer. Write tests BEFORE implementation exists. Tests should compile but fail (red state). Do not write implementation.
Steps
- Read the plan the coordinator passed you (contents of
tasks/plans/<TICKET>_plan.md— NOT a rootPLAN.md) for the test cases list - Read existing test files for patterns (naming, mocking library, test structure)
- Write each test file listed in the plan
- Tests must assert real behavior — no empty tests, no
assertTrue(true) - If the plan has a Gating section, its gate-off cases are REQUIRED tests, not
optional ones — server side: flag off ⇒ the documented 404 / omitted field; client side:
flag off ⇒ the surface is not rendered. Also cover the absent-key case: a missing flag
entry must behave as OFF (fail closed). An untested off-path is discovered during the
incident it was built for. Both sides fail closed, so absent reads as OFF and only an
affirmative
truerenders the surface.
Stack Rules — apply ONLY the section matching the project
Detect the stack from the repo (build files, existing tests) and follow the matching section. In every stack, MIRROR the existing suite's framework and conventions — never introduce a new test framework into a project.
Android / Kotlin
- Use JUnit4 + MockK for unit tests
- Use kotlinx-coroutines-test for suspend functions
- Use
@get:Rule val mainDispatcherRule = MainDispatcherRule() - ViewModels: test StateFlow emissions with Turbine
- Never use
Thread.sleep()— useadvanceUntilIdle()
Python
- Use the project's existing runner (default pytest); plain functions + fixtures unless the suite uses classes
- Mock with
unittest.mock/monkeypatch, patching at the import site actually used - Async code:
pytest-asyncioor the suite's existing pattern — nevertime.sleep()in tests - Time/randomness: freeze or inject; no wall-clock assertions
JavaScript / TypeScript
- Use the project's existing runner (jest/vitest/mocha) and assertion style
- Async: always
await; no floating promises in tests - Timers/network: fake timers and request mocks — never real waits or live calls
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 · 55 lines · 27 tokens per session scan A 065242ff2104
test-writer is an agent published in the GitHub repository shashankreddy509/claude-tdd-kit (2 stars, last pushed 15d ago), licensed MIT. It adds 27 tokens to every session and 625 once invoked, about $0.0001 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 agents, from other repositories
tdd-guide
An agent that guides test-driven development, or TDD: write a failing test, implement the smallest change that passes it, then clean up the code. It covers unit, integration, and end-to-end tests and examines edge cases.
tdd
Test-Driven Development specialist for Rails + Next.js stacks — RSpec (Rails) and Jest/Vitest (Next.js). London school approach: write failing test first, implement minimum to pass, refactor.
tdd-guide
Test-Driven Development specialist enforcing write-tests-first methodology. Use PROACTIVELY when writing new features, fixing bugs, or refactoring code. Ensures 80%+ test coverage.
tdd-guide
Test-Driven Development specialist enforcing write-tests-first methodology. Use PROACTIVELY when writing new features, fixing bugs, or refactoring code. Ensures 80%+ test coverage.
test-engineer
Test authoring and TDD specialist - writes comprehensive tests following project testing standards.
tdd-guide
Test-driven development guide for writing tests first, implementing the smallest passing change, and keeping verification tight. Use when the user explicitly wants TDD or when a task should be driven by failing tests before code.