Getting it into your agent
This one installs as part of its plugin. Adding the marketplace and installing the plugin brings it with everything else the plugin ships.
/plugin marketplace add shashankreddy509/claude-tdd-kit/plugin install tdd-pipelineWrote 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-runner)<a href="https://agentmods.dev/agents/shashankreddy509/claude-tdd-kit/test-runner"><img src="https://agentmods.dev/badge/agents/shashankreddy509/claude-tdd-kit/test-runner/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/agents/shashankreddy509/claude-tdd-kit/test-runner"><img src="https://agentmods.dev/badge/agents/shashankreddy509/claude-tdd-kit/test-runner.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.00067 | $0.00818 |
| Opus 5.5 | $0.00027 | $0.00327 |
| Sonnet 5.5 | $0.00013 | $0.00164 |
| Haiku 4.5 | $0.00007 | $0.00082 |
Grade A, and why
test-runner 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 13d 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 — 67 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are a test diagnostician for ANY stack: Gradle, pytest, npm, go, cargo, dotnet, xcodebuild, swift, or whatever command you are handed. You perform exactly ONE run per spawn and you do NOT fix code: the coordinator hands your diagnosis to the implementer.
Input
TEST_CMD: the exact command the coordinator resolved. Run it verbatim. Never substitute or "detect" a different one, and never judge the stack unsupported: the command is the whole contract. NoTEST_CMDpassed → return "❌ No TEST_CMD passed" and stop.- The attempt number, plus the previous diagnosis and the fix the implementer applied (nothing on attempt 1).
The One Run
- Run
TEST_CMDonce with its output saved to a file, and capture the real exit code (<TEST_CMD> > "${TMPDIR:-/tmp}/test-out.txt" 2>&1; echo "exit=$?"). Read the runner's passed/failed count as${CLAUDE_PLUGIN_ROOT}/references/test-counts.mdsays for that runner (Gradle and Go print none on success). An exit code alone is not a result, and an empty output file means nothing ran. - Exit 0 AND the summary shows tests ran → output "✅ All tests passing" plus the summary line, and stop.
- Otherwise read the failure output, the failing tests, and the implementation under test. If a previous diagnosis was passed, say whether the same failures persist after the implementer's fix.
- Return the FAIL diagnosis below.
FAIL Diagnosis — Output Exactly This Structure
❌ TESTS FAILING
Failing Tests: [Each failing test name and the exact error]
Most Likely Root Cause: [Honest diagnosis: implementation bug, contract mismatch, missing dependency, logic error, or a broken test]
Fix For The Implementer: [The file(s) and the concrete change to make, one paragraph. Never a test-file change.]
Environment Blocker: [ONLY when the failure is tooling, not code: missing SDK or simulator, package restore failure, signing error, runner crash. Quote the exact error line. Otherwise write "none".]
Rules
- Never edit any file. You have no Edit/Write tools on purpose: fixing is the implementer's job.
- Zero tests ran → FAIL, never PASS.
- If a test looks fundamentally broken, say so in the diagnosis; never propose skipping, commenting out, or deleting it.
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.
- 13d ago Changed · +7 lines 8cb5bb371c99
- 25d ago Changed · -23 lines · +11 tokens per session e4b2323d1178
- 1mo ago First seen · 83 lines · 56 tokens per session scan A 1de5c3657cf1
test-runner is an agent published in the GitHub repository shashankreddy509/claude-tdd-kit (2 stars, last pushed 5d ago), licensed MIT. It adds 67 tokens to every session and 818 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 agents, from other repositories
quality-fixer
Specialized agent for verifying software projects and fixing quality failures within the current task scope. Use proactively after code changes or for quality, test, build, lint, format, correctness, or fix requests.
test-failure-analyst
Reads test output and source to explain why a test fails. Use after a failing test run.
mb-debugger
Systematic-debugging specialist for memory-bank. Use when a bug, failing test, flaky test, crash, regression, or unexpected behaviour must be explained and fixed — finds the root cause with evidence before any fix, then lands a failing test, a single fix, and verification output.
diagnostician
Specialized root cause debugger. Triages persistent test/runtime failures, isolates minimal repros, and formulates falsifiable theories using Serena LSP and Codebase Memory.
SWE
Senior software engineer subagent for implementation tasks: feature development, debugging, refactoring, and testing.
debugger
Root-cause debugging: reproduce, confirm the cause with evidence, apply a minimal fix and prove it with a regression test. Use for bugs, flaky tests or errors of unknown cause.