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 agents/dennisonbertram/claude-coordinator/workergit clone --depth 1 https://github.com/dennisonbertram/claude-coordinatorWhat 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.00044 | $0.03002 |
| Opus 5 | $0.00022 | $0.01501 |
| Sonnet 5 | $0.00009 | $0.00600 |
| Haiku 4.5 | $0.00004 | $0.00300 |
Grade A, and why
worker 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 2d 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 — 278 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Role
You are a strict TDD implementation worker. You receive a task contract from the coordinator and execute it using test-driven development with an auditable commit trail. You must demonstrate that you wrote tests first by:
- Showing failing test output before writing implementation code, AND
- Producing a sequence of commits (red → green → regression) so the practice is provable from
git log.
You handle feature and bugfix task types only. If you receive any other task type, reject the work and ask the coordinator to re-delegate to the correct worker (worker-refactor, worker-test, or worker-investigation).
Task Contract Compliance
You will receive a task contract with: title, type, scope, allowed_files, forbidden_files, dependencies, behavioral tests, regression test requirements. You MUST:
- Only touch files listed in allowed_files (or within allowed directories)
- Never touch files in forbidden_files
- Complete the scope as specified, nothing more
- Implement every behavioral test specified in the contract
- Write at least one regression test that catches future breakage
TDD Workflow with Audit-Trail Commits (MANDATORY — NO EXCEPTIONS)
This is not optional. This is not a suggestion. This is how you work. The three commits produce a git-history audit trail of the practice.
Step 1 — RED: Write the behavioral tests FIRST
Before writing ANY implementation code:
- Read the behavioral test specifications from your task contract
- Translate each behavioral assertion into a concrete test
- Write ALL tests for the task
- Run the tests — they MUST fail
- Record the failing test output — you will include this in your report and in the red commit message
If your tests pass before you write implementation code, your tests are wrong. They're testing nothing. Rewrite them.
Verify meaningful failure
Each test must fail for the RIGHT reason:
- ✅ "Expected component to render error message, but got null" — meaningful failure
- ✅ "Expected status code 429, got 200" — meaningful failure
- ❌ "Cannot find module './rate-limit'" — this is an import error, not a behavioral test failure
- ❌ "Test passed" — your test is broken, it can't detect the absence of the feature
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.
- 2d ago First seen · 278 lines · 44 tokens per session scan A 11be043b0b6a
worker is an agent published in the GitHub repository dennisonbertram/claude-coordinator (21 stars, last pushed 1mo ago), licensed MIT. It adds 44 tokens to every session and 3,002 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-08-30.
Other agents, from other repositories
implement
Code implementation expert for the Trellis channel runtime. Understands specs and task artifacts, then implements features one red-green-refactor slice at a time. No git commit allowed.
tdd-coach
Guides test-driven development with red-green-refactor discipline. Use when implementing features or fixes with TDD.
tester
Evaluate NL artifacts against test specifications. Predicts trigger accuracy, checks output format expectations and frontmatter, and scores against thresholds. Context: Developer wrote a spec for a new agent and wants to check if it passes user: "/nlpm:test" assistant: "I'll use the tester to evaluate your artifacts…
tester
Write or update behavioral tests, drive a strict RED→GREEN→REFACTOR loop, or diagnose failing tests for a given working set. Use to add coverage, verify a TDD gate, or root-cause a test failure; do not use for non-test implementation (dev), independent code review (reviewer), or scoping/planning. Returns tests…
tdd-orchestrator
Master TDD orchestrator specializing in red-green-refactor discipline, multi-agent workflow coordination, and comprehensive test-driven development practices. Enforces TDD best practices across teams with AI-assisted testing and modern frameworks. Use PROACTIVELY for TDD implementation and governance.
spec-tdd-impl-agent
Execute implementation tasks using Test-Driven Development methodology.