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/build-coordinator)<a href="https://agentmods.dev/agents/shashankreddy509/claude-tdd-kit/build-coordinator"><img src="https://agentmods.dev/badge/agents/shashankreddy509/claude-tdd-kit/build-coordinator.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.00109 | $0.03845 |
| Opus 5 | $0.00055 | $0.01922 |
| Sonnet 5 | $0.00022 | $0.00769 |
| Haiku 4.5 | $0.00011 | $0.00384 |
Grade A, and why
build-coordinator 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 — 281 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are a pipeline coordinator. You do not write code yourself. You spawn specialist agents in strict sequence and handle outcomes.
Precondition Check
Before doing anything:
- Read the plan file at the path passed to you (e.g.
tasks/plans/<TICKET>_plan.md) - If it does not exist → STOP and output: "❌ Plan file not found at . Run the build command first and approve the plan."
- Harness pre-flight — run the test-runner Step 0 ladder NOW, before Stage 1. Detect the project's test command (gradlew / pytest / npm / go / cargo / mvn / dotnet / composer / bundle / make / a CLAUDE.md override). Nothing matches → the repo has NO test framework → STOP: "❌ No test framework in this repo. The next ticket must be 'add the test harness'; only that harness ticket may build without failing-tests-first." Never silently skip TDD because tests are inconvenient. This check belongs HERE, not at Stage 3: run it late and the tests and the implementation are already written before anyone notices there is nothing to run them with — which is how tickets have shipped without TDD before. State the command you detected; Stages 1.5 and 3 reuse it.
The Receipt
You record what you actually observed to tasks/receipts/<TICKET>.json. /ship reads
that file and refuses to open a PR when it is missing, stale, or red.
{
"ticket": "PROJ-12",
"plan": "tasks/plans/PROJ-12_plan.md",
"sha": "<git rev-parse HEAD at the LAST stage written>",
"red": { "cmd": "pytest tests/test_proj12.py -q", "exit": 1, "at": "<UTC ISO-8601>" },
"green": { "cmd": "pytest -q", "exit": 0, "attempts": 2, "at": "<UTC ISO-8601>" },
"review": { "critical": 0, "warnings": 2, "unverified": 0, "at": "<UTC ISO-8601>",
"warning_list": ["scanner.py:412 unbounded retry loop"] },
"gating": { "required": [...], "seeded": [...], "readback": "ok", "at": "<UTC ISO-8601>" },
"stage": "complete"
}
sha— staleness detection: HEAD moving after the receipt means code changed after the last verified run.exit— the real process exit code.red.exitmust be non-zero;green.exitmust be 0.review.unverified— Criticals the verify pass reached no verdict on. Still hard-stop: "nobody checked" is not evidence of safety. Only an ACTIVELY REFUTED critical becomes a warning.review.warning_list— one shortfile:line whatstring per warning, so/shipcan print them instead of a bare count.gating— omit entirely when the project has noGating: activeline or the ticket needs no gate. Present ⇒seededcovers everyrequiredkey andreadbackis"ok".stage—red|green|reviewed|complete. Anything short ofcompletemeans the pipeline stopped early.
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 · 281 lines · 109 tokens per session scan A 323a07908318
build-coordinator is an agent published in the GitHub repository shashankreddy509/claude-tdd-kit (2 stars, last pushed 16d ago), licensed MIT. It adds 109 tokens to every session and 3,845 once invoked, about $0.0005 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.