| name | tdd-implement |
| description | Execute TDD implementation with a 3-agent team (QA, Implementor, Reviewer) following Red-Green-Review cycle. Use when Claude needs to (1) implement features using TDD methodology, (2) run a multi-agent team for code changes, (3) enforce minimal working code through test-driven development. Triggers on "tdd", "implement with tdd", "tdd team", "red green refactor", "tdd implement". |
TDD Team Implementation
User Input
$ARGUMENTS
Consider user input before proceeding (if not empty).
Prerequisites
The lead shall read .specify/memory/serena/index.md for relevant memories before starting.
The lead shall read .specify/memory/constitution.md for project principles and constraints before starting.
The lead shall read spec/plan/tasks files for the current feature (if they exist).
The lead shall read CLAUDE.md for quality gates.
Lead Role — Coordination Only
CRITICAL: The lead shall NOT write code, edit files, run tests, or fix issues directly. The lead is a coordinator:
- The lead shall delegate ALL implementation work to implementor.
- The lead shall delegate ALL test writing to qa.
- The lead shall delegate ALL quality gate execution to qa.
- The lead shall delegate ALL review work to reviewer.
- The lead shall only read files for context, create tasks, assign work, and forward messages between agents.
- The lead shall send fix instructions to the appropriate agent — never apply fixes itself.
- If an agent fails after 3 attempts on the same issue, the lead shall spawn a replacement agent rather than doing the work.
The lead's tools: TeamCreate, TaskCreate, TaskUpdate, TaskList, SendMessage, Read, Glob, Grep (read-only exploration). The lead shall not use Edit, Write, or Bash for code changes.
Core Principles
Include in EVERY agent prompt. See references/agent-rules.md for full text.
Each agent shall write the smallest amount of code that satisfies requirements and tests.
Each agent shall prefer simple solutions over clever ones.
Each agent shall not add features, handling, or abstractions beyond requirements or tests.
Each agent shall not add docstrings, comments, type hints, or refactoring beyond what the task demands.
Each agent shall treat requirements as the maximum scope ceiling.
Team
Create via TeamCreate, then spawn 3 agents:
| Role | Model | subagent_type |
|---|
| qa | sonnet | general-purpose |
| implementor | sonnet | general-purpose |
| reviewer | opus | general-purpose |
Agent Communication Rules
CRITICAL: Agents do not automatically report results or mark tasks done. Every agent prompt MUST include these instructions:
- Task completion: Every agent prompt shall end with: "When done, mark task #N as completed using TaskUpdate, then send a message to team-lead using SendMessage with type 'message' containing your results summary."
- QA reporting only: QA prompts shall include: "Do NOT fix anything — only report results. Mark task as completed if all gates pass, leave in_progress if failures."
- Reviewer forwarding: The lead shall forward reviewer issues to implementor via SendMessage with exact file:line references and code fixes. Never expect the reviewer to message the implementor directly.
- Re-verification after fix: When sending fixes to implementor, include: "After fixing, run [specific verification command] to confirm clean, then message team-lead with results."
- Idle is normal: Agents go idle after every turn. Do not treat idle notifications as errors or completion signals — wait for the actual SendMessage from the agent.
Workflow
RED → GREEN → QUALITY GATES → REVIEW → (REVISE loop, max 3) → DONE
Phase 1: RED — Failing Tests
Assign to qa. Use prompt from references/qa-prompt.md.
The lead shall substitute {REQUIREMENTS} with requirements from user input or spec files.
The lead shall append to qa prompt: "When done, mark task #N as completed using TaskUpdate, then send a message to team-lead via SendMessage with test file paths and confirmation they fail."
When qa completes, the lead shall verify tests exist and fail via go test ./....
Phase 2: GREEN — Minimal Implementation
Assign to implementor. Use prompt from references/implementor-prompt.md.
The lead shall append to implementor prompt: "When done, mark task #N as completed using TaskUpdate, then send a message to team-lead via SendMessage with files changed and test results."
When implementor completes, the lead shall verify all tests pass.
Phase 3: Quality Gates
Assign to qa (or spawn dedicated qa agent). The lead shall instruct qa:
- Run all quality gate commands
- Report results only — do NOT fix anything
- Mark task as completed if all pass, leave in_progress if failures
- Send results to team-lead via SendMessage
The lead may run quality gates in parallel with the reviewer (Phase 4) since both are read-only.
gofmt -l .
go vet ./...
go test -v -race ./...
govulncheck ./...
gosec ./...
If any quality gate fails, then the lead shall send exact error output to implementor via SendMessage for fix, including: "After fixing, run [failed command] to verify clean, then message team-lead."
Phase 4: Review
Assign to reviewer. Use prompt from references/reviewer-prompt.md.
The lead shall append: "Send your review to team-lead via SendMessage. Do NOT message implementor directly."
The reviewer shall return PASS or REVISE with specific file:line issues.
Phase 5: Revise (if needed)
When reviewer returns REVISE, the lead shall forward specific issues to implementor via SendMessage with exact code suggestions and file:line references.
The lead shall include in the message: "After fixing, run [verification command] to confirm, then message team-lead."
The implementor shall fix only the flagged issues.
When implementor completes fixes, the lead shall re-run quality gates (Phase 3).
When quality gates pass, the lead shall re-send to reviewer.
If revise cycle exceeds 3 iterations, then the lead shall spawn a fresh implementor agent with accumulated context and fixes.
Task List
The lead shall create these tasks at start:
Write failing tests (RED) — qaImplement minimal code (GREEN) — implementor, blocked by #1Run quality gates — blocked by #2Review changes — reviewer, blocked by #3Apply review fixes — blocked by #4Final quality gates and cleanup — blocked by #5
Error Handling
If qa writes tests that error on missing types/packages, then the lead shall instruct qa via SendMessage to write interface-based tests or use stub implementations so tests fail on assertions instead.
If implementor cannot make tests pass after 2 attempts, then the lead shall shutdown the implementor and spawn a fresh implementor agent with full context of the problem.
If reviewer suggests scope-expanding changes, then the lead shall reject them via SendMessage and request review within stated criteria only.
If any agent is unresponsive after 2 messages, then the lead shall shutdown that agent and spawn a replacement with the same role.
Completion
When all phases complete, the lead shall assign final quality gates to qa.
When qa confirms all gates pass, the lead shall shutdown all agents via SendMessage type: "shutdown_request".
When all agents shut down, the lead shall clean up with TeamDelete.
The lead shall report: files changed, tests added, review outcome.
