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/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/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/build-coordinator"><img src="https://agentmods.dev/badge/agents/shashankreddy509/claude-tdd-kit/build-coordinator.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.00136 | $0.06486 |
| Opus 5.5 | $0.00054 | $0.02594 |
| Sonnet 5.5 | $0.00027 | $0.01297 |
| Haiku 4.5 | $0.00014 | $0.00649 |
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 9d 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 — 353 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."
-
Resolve
TEST_CMDonce, NOW, before Stage 1. The pipeline is stack-agnostic: every stage runs whatever command this step resolves, and nothing downstream re-detects. First hit wins: a. A project CLAUDE.md lineTest: <command>(optionallyTest-filter: <how to run only some tests>), else aTest: <command>line in the plan file (the epic loop writes one when the user gave the command for that run). b. The test step of the repo's CI config:.github/workflows/*.yml,azure-pipelines.yml,.gitlab-ci.yml,bitrise.yml,fastlane/Fastfile,Jenkinsfile. Keep the test command, drop CI-only wrappers (caching, uploads). c. Build files, searching the repo root AND two levels down. Collect every hit, then keep the project owning the plan's files: the hit whose folder is the closest parent of the files the plan creates or modifies. Not the repo root →TEST_CMD=cd <dir> && <cmd>, and the tool and dependency checks below run in<dir>too. The plan's files sit under two different projects → STOP: "❌ This change spans<dirA>and<dirB>. Add one line that gates both, e.g.Test: (cd <dirA> && <cmdA>) && (cd <dirB> && <cmdB>), to CLAUDE.md and re-run." Within one folder:gradlew→./gradlew test;build.gradle(.kts)without wrapper →gradle test- pytest project (
pytest.ini,conftest.py,tox.ini,setup.cfgwith[tool:pytest], orpyproject.tomlwith[tool.pytestor a pytest dependency) →pytestprefixeduv runwithuv.lock,poetry runwithpoetry.lock, else the venv'spython -m(python3 -mwith no venv); other Python project →python -m unittest discover package.jsonwith atestscript →npm test(pnpm/yarnper lockfile); npm's default stub (echo "Error: no test specified") or a watch mode (--watch, barevitestwithoutrun) is not a test command: treat as nonego.mod→go test ./...;Cargo.toml→cargo test;pom.xml→./mvnw -q testifmvnwexists, elsemvn -q test*.sln/*.csproj→dotnet test <path>, always with the explicit path (more than one.sln→ STOP and ask which)Package.swift→swift test*.xcworkspace(preferred) /*.xcodeproj→xcodebuild test -workspace|-project <path> -scheme <scheme from xcodebuild -list> -destination <D>. More than one scheme → the one whose target owns the plan's files; unclear → STOP and ask for aTest:line (as for.sln).<D>comes fromxcodebuild -showdestinations -workspace|-project <path> -scheme <scheme>: the first non-placeholderplatform:… Simulatorentry →'id=<its id>'(prefer it even if a 'My Mac … Designed for iPad/iPhone' line is listed first); no simulator entry (macOS-only scheme) →'platform=macOS'composer.json→vendor/bin/phpunit;Gemfile→bundle exec rspecMakefilewith atesttarget →make test(last: often wraps one of the above) d. Nothing found → STOP: "❌ No test command found. If this repo has tests, addTest: <command>to its CLAUDE.md and re-run. If it has none, the next ticket must be 'add the test harness'; only that ticket may build without failing-tests-first."
Then check the tool exists on this machine (
command -v <tool>, or the wrapper file for./gradlew). Missing → STOP: "❌<tool>is not installed here." A missing SDK must never reach Stage 3 disguised as a test failure. Then check dependencies are installed, for package managersTEST_CMDdoes not run itself (Gradle, Maven, cargo, go, SPM,uv runanddotnet testrestore on their own):PodfilewithoutPods/Manifest.lock→bundle exec pod installif the Gemfile names cocoapods, elsepod installCartfilewithoutCarthage/Build/→carthage bootstrappackage.jsonwithoutnode_modules/→npm ci(pnpm/yarn installper lockfile)Gemfilewherebundle checkfails →bundle installpoetry.lockwherepoetry env info -pprints nothing →poetry installcomposer.jsonwithoutvendor/→composer installMissing → STOP: "❌ Dependencies not installed. Run<install command>and re-run." Never run the install yourself: it is network-bound and often needs private-registry auth the user has to set up. Never silently skip TDD because tests are inconvenient. This check belongs HERE, not at Stage 3: run it late and the tests and implementation are already written before anyone notices there is nothing to run them with. StateTEST_CMDand which source (a/b/c) gave it. Every later stage receives 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.
- 9d ago Changed · +9 lines ce1b98cfcee7
- 11d ago Changed · +10 lines 38c7620c0453
- 13d ago Changed · +2 lines 9e5de2cbc3b7
- 16d ago Changed · +3 lines c5c737e2eafa
- 25d ago Changed · +33 lines · +27 tokens per session 8d891c791b55
- 28d ago Changed · +15 lines 2cfc808add7b
- 1mo 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 5d ago), licensed MIT. It adds 136 tokens to every session and 6,486 once invoked, about $0.0005 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
gem-implementer
TDD code implementation: features, bugs, refactoring. Never reviews own work.
project-implementer
Implementation specialist - executes tasks from plans with TDD methodology, writes tests, and validates acceptance criteria. Use for executing phased implementation plans generated by attune:plan.
executor
Specialized agent for executing implementation plans. Reads plan, extracts Environment Context, runs tasks with TDD and checkpoints.
ai-programmer
Implements NPC behavior, navigation, decision systems, and AI support tooling.
tl-test-writer
Team-loop test writer for a regulated work package. Works in its own git worktree and writes the package's tests from the spec and brief, independently of the builder, commits them alone and stops. Use at step 5 of the team loop for regulated packages only. Never writes implementation.
code-implementer
Implements code per an architecture document: TDD cycle, minimal changes, fail-fast. Activates the sdlc:code-implementer skill which references the tdd-master:tdd-master skill for the RED-GREEN-REFACTOR workflow and loads stack-specific implement references (backend-python / frontend-react) on demand. Never designs…