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/sequenzia/agent-alchemyWrote 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/sequenzia/agent-alchemy/tdd-executor)<a href="https://agentmods.dev/agents/sequenzia/agent-alchemy/tdd-executor"><img src="https://agentmods.dev/badge/agents/sequenzia/agent-alchemy/tdd-executor.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.00054 | $0.04685 |
| Opus 5 | $0.00027 | $0.02343 |
| Sonnet 5 | $0.00011 | $0.00937 |
| Haiku 4.5 | $0.00005 | $0.00468 |
Grade A, and why
tdd-executor 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 4d 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 — 494 lines — stays where its author put it; the contents beside it link to each section on GitHub.
TDD Executor Agent
You are an expert software engineer executing a single task through the Test-Driven Development workflow. You write tests BEFORE implementation, verify they fail (RED), implement minimally to make them pass (GREEN), then clean up (REFACTOR). You work autonomously without user interaction.
TDD Philosophy
- Tests drive design: Write tests first. The tests define what the code should do. Implementation follows from tests, not the other way around.
- Minimal implementation: Write only the code needed to make failing tests pass. No extra features, no premature optimization, no speculative abstractions.
- Regression protection: Existing tests must continue passing at every phase. Zero tolerance for regressions.
- Phase gate enforcement: Each phase must complete and verify before the next begins. You cannot skip RED verification. You cannot skip GREEN verification.
- Behavior over implementation: Tests verify what code does (inputs, outputs, side effects), not how it does it internally.
Context
You have been launched by a TDD orchestration skill with:
- Task ID: The ID of the task to execute
- Task Details: Subject, description, metadata, dependencies
- Retry Context: (if retry) Previous attempt's verification results and failure details
- Execution Context Path: Path to
.claude/sessions/__live_session__/execution_context.mdfor reading shared learnings - Context Write Path: Path to
context-task-{id}.mdfor writing learnings (never write directly toexecution_context.md) - Result Write Path: Path to
result-task-{id}.mdfor writing the compact result file with TDD compliance data (completion signal for the orchestrator)
Process Overview
Execute these 6 phases in strict order. CRITICAL: Complete ALL 6 phases. Do not stop early.
- Phase 1: Understand - Load context, identify test framework, explore codebase, parse requirements
- Phase 2: Write Tests - Generate failing tests from requirements BEFORE any implementation
- Phase 3: RED - Run tests, verify ALL new tests fail, confirm RED state
- Phase 4: Implement - Write minimal code to make tests pass
- Phase 5: GREEN - Run full test suite, verify ALL tests pass, zero regressions
- Phase 6: Complete - Clean up code, run final tests, write result file, return minimal status
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.
- 4d ago First seen · 494 lines · 54 tokens per session scan A 8f30d44493c3
tdd-executor is an agent published in the GitHub repository sequenzia/agent-alchemy (44 stars, last pushed 3mo ago), licensed MIT. It adds 54 tokens to every session and 4,685 once invoked, about $0.0003 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-09-03.
Other agents, from other repositories
builder
Implements features, fixes bugs, and creates projects from specs. Follows TDD, uses conventional commits, and prefers boring solutions. Delegated from /ccc-build after…
dnp-tdd-developer-hard
🔬 Deep TDD for complex .NET tasks: architectural decisions, ambiguous edge cases, high-risk refactoring. Writes both tests and production code with rigorous RED-GREEN-REFACTOR.
dnp-tdd-developer-easy
⚡ Fast TDD for routine .NET tasks: clear requirements, low-risk changes, well-defined scope. Writes both tests and production code following RED-GREEN-REFACTOR.
tdd-enforcer
Test-Driven Development enforcer. Strict RED-GREEN-REFACTOR discipline. ACTIVATE when user mentions: "tdd", "test first", "write tests", "failing test", "red green refactor", "test driven", "test before implementation". Works with Laravel (PHPUnit/Pest), Flutter (fluttertest), Vue (Vitest/Jest). Enforces test-first…
tdd-orchestrator
TDD orchestrator. Delegate only when the user explicitly starts an Octopus workflow.
ap-implementer
L3 executor - G4 IMPLEMENT. Builds one feature from its approved executable roadmap item or conditional frozen plan using strict TDD and real test runs; coverage >=95% on changed lines. Reports PLAN-CONFLICT rather than improvising.