Agent skill
execute-tdd-tasks
Execute TDD task pairs autonomously with RED-GREEN-REFACTOR verification. Orchestrates wave-based execution with strategic parallelism, routing TDD tasks to tdd-executor agents and non-TDD tasks to standard task-executor. Use when user says "execute tdd tasks", "run tdd tasks", "start tdd execution", or wants to execute TDD-paired tasks from create-tdd-tasks.
Install this agent skill to your Project
npx add-skill https://github.com/majiayu000/claude-skill-registry/tree/main/skills/other/other/execute-tdd-tasks
SKILL.md
Execute TDD Tasks Skill
This skill orchestrates autonomous execution of TDD task pairs generated by /create-tdd-tasks. It is the TDD counterpart to the standard execute-tasks skill, reusing its session management, wave infrastructure, and execution context sharing while adding TDD-specific agent routing, RED-GREEN-REFACTOR verification, and per-task compliance reporting.
The key difference from standard execute-tasks: this skill routes TDD tasks to the tdd-executor agent (from tdd-tools) which runs a 6-phase TDD workflow, while routing non-TDD tasks to the standard task-executor agent. It verifies TDD compliance (RED verified, GREEN verified, refactored) per task pair and reports aggregate results.
CRITICAL: Complete ALL 10 steps. The workflow is not complete until Step 10: Update CLAUDE.md is evaluated. After completing each step, immediately proceed to the next step without waiting for user prompts (except Step 6 which requires user confirmation).
Cross-Plugin Dependency
This skill requires the tdd-tools plugin to be installed. It uses:
- tdd-executor agent (Opus) -- 6-phase TDD workflow per task
- test-writer agent (Sonnet) -- parallel test generation (used by tdd-executor internally)
If tdd-tools is not installed, this skill MUST abort with a clear error before launching any agents. See Step 2 for the detection and error handling procedure.
Core Principles
1. TDD Compliance First
Every TDD task pair must complete the RED-GREEN-REFACTOR cycle:
- RED: Tests are written and verified to fail before any implementation exists
- GREEN: Implementation is written that makes all tests pass with zero regressions
- REFACTOR: Code is cleaned up while keeping all tests green
2. Strategic Parallelism
Maximize execution throughput without violating TDD sequencing:
- PARALLEL: Multiple test-writing tasks (RED phase) run simultaneously across features
- SEQUENTIAL: Within a single TDD pair, RED must complete before GREEN can start (enforced by dependencies)
3. Reuse execute-tasks Infrastructure
Session management, wave execution, context sharing, and progress tracking all reuse the same patterns from execute-tasks. See references/tdd-execution-workflow.md for TDD-specific extensions.
4. Honest TDD Reporting
Report per-task compliance with the full RED-GREEN-REFACTOR cycle:
red_verified: Whether tests failed as expected before implementationgreen_verified: Whether all tests pass after implementationrefactored: Whether code was cleaned up while maintaining green testscoverage_delta: Change in test coverage percentage (if measurable)
Orchestration Workflow
This skill orchestrates TDD task execution through a 10-step loop that mirrors the standard execute-tasks orchestration with TDD-specific extensions. See references/tdd-execution-workflow.md for the full TDD wave execution details and references/tdd-verification-patterns.md for TDD phase verification rules.
Step 1: Load References
Read the TDD-specific reference files:
Read: ${CLAUDE_PLUGIN_ROOT}/skills/execute-tdd-tasks/references/tdd-execution-workflow.md
Read: ${CLAUDE_PLUGIN_ROOT}/skills/execute-tdd-tasks/references/tdd-verification-patterns.md
Parse arguments from the invocation:
--task-group <group>-- Filter tasks to a specific group--max-parallel <n>-- Override max concurrent agents per wave--retries <n>-- Override retry attempts per task (default: 3)
Step 2: Validate Prerequisites
Check tdd-tools plugin availability:
Before loading tasks, verify that the tdd-tools plugin is available by checking for the tdd-executor agent. If the agent cannot be found, abort with a clear error:
ERROR: tdd-tools plugin is required for TDD task execution.
The following agents are needed but not available:
- tdd-executor (from tdd-tools) -- executes TDD task pairs with 6-phase workflow
- test-writer (from tdd-tools) -- generates tests in parallel
Install tdd-tools:
1. Add tdd-tools to your .mcp.json plugin configuration
2. Restart Claude Code to load the plugin
3. Re-run /execute-tdd-tasks
Alternatively, use /execute-tasks to run tasks without TDD enforcement.
Do NOT fall back to standard execution. The user explicitly requested TDD execution.
Step 3: Load and Classify Tasks
Use TaskList to retrieve all tasks. If --task-group was provided, filter to tasks where metadata.task_group matches.
Classify each task by type:
| Detection | Type | Agent |
|---|---|---|
metadata.tdd_mode == true AND metadata.tdd_phase == "red" |
TDD test task | tdd-executor |
metadata.tdd_mode == true AND metadata.tdd_phase == "green" |
TDD implementation task | tdd-executor |
No tdd_mode metadata or tdd_mode == false |
Non-TDD task | task-executor |
Count and report:
- Total tasks (pending + in_progress + completed)
- TDD pairs identified (test + implementation tasks)
- Non-TDD tasks
- Already completed tasks
Handle edge cases:
- No tasks found: Report "No tasks found for group '{group}'. Use
/create-tdd-tasksto generate TDD task pairs from your SDD tasks." and stop. - All completed: Report a summary of completed tasks including TDD compliance and stop.
- No unblocked tasks: Report which tasks exist and what's blocking them.
Step 4: Build Execution Plan
Resolve max_parallel using precedence:
--max-parallelCLI argument (highest priority)max_parallelin.claude/agent-alchemy.local.md- Default: 5
Resolve retries using precedence:
--retriesCLI argument (highest priority)- Default: 3
Read .claude/agent-alchemy.local.md if it exists, for TDD-specific settings:
tdd.strictness--strict,normal(default), orrelaxedtdd.coverage-threshold-- Minimum coverage target (default: 80)
Build the dependency graph from all pending tasks (TDD and non-TDD):
- Collect all pending tasks and their
blockedByrelationships - Run topological sort to assign dependency levels
- Assign tasks to waves by dependency level (Wave 1 = no dependencies, Wave 2 = depends only on Wave 1, etc.)
- Sort within waves by priority: critical > high > medium > low > unprioritized
- Break ties by "unblocks most others"
- Cap each wave at
max_paralleltasks
Annotate waves with TDD phase labels:
The dependency structure from create-tdd-tasks naturally produces alternating test/implementation waves:
Wave 1: [Test-A, Test-B, Test-C] -- RED phase (parallel test generation)
Wave 2: [Impl-A, Impl-B, Impl-C] -- GREEN phase (parallel implementation)
Wave 3: [Test-D, Test-E, Non-TDD-F] -- RED phase + non-TDD tasks (mixed)
Wave 4: [Impl-D, Impl-E] -- GREEN phase
Detect circular dependencies: If tasks remain unassigned after topological sorting, they form a cycle. Report the cycle and attempt to break at the weakest link.
Validate TDD pair cross-references: For each TDD task, verify its paired_task_id references a valid task. Log warnings for orphaned pairs.
Step 5: Present Execution Plan and Confirm
Display the TDD execution plan:
EXECUTION PLAN (TDD Mode)
Tasks to execute: {count} ({tdd_pairs} TDD pairs, {non_tdd} non-TDD tasks)
Retry limit: {retries} per task
Max parallel: {max_parallel} per wave
TDD Strictness: {strict|normal|relaxed}
WAVE 1 ({n} tasks -- RED phase):
1. [{id}] Write tests for {subject} (RED, paired: #{impl_id})
2. [{id}] Write tests for {subject} (RED, paired: #{impl_id})
WAVE 2 ({n} tasks -- GREEN phase):
3. [{id}] {subject} (GREEN, paired: #{test_id})
4. [{id}] {subject} (GREEN, paired: #{test_id})
WAVE 3 ({n} tasks -- mixed):
5. [{id}] {subject} (non-TDD)
6. [{id}] Write tests for {subject} (RED, paired: #{impl_id})
{Additional waves...}
BLOCKED (unresolvable dependencies):
[{id}] {subject} -- blocked by: {blocker ids}
COMPLETED:
{count} tasks already completed
Use AskUserQuestion to confirm:
questions:
- header: "Confirm TDD Execution"
question: "Ready to execute {count} tasks in {wave_count} waves (max {max_parallel} parallel) with TDD enforcement ({strictness} mode)?"
options:
- label: "Yes, start TDD execution"
description: "Proceed with the TDD execution plan above"
- label: "Cancel"
description: "Abort without executing any tasks"
multiSelect: false
If the user selects "Cancel", report "Execution cancelled. No tasks were modified." and stop.
Step 6: Initialize Execution Directory
Generate a task_execution_id using three-tier resolution:
- IF
--task-groupwas provided:{task_group}-tdd-{YYYYMMDD}-{HHMMSS} - ELSE IF all open tasks share the same
metadata.task_group:{task_group}-tdd-{YYYYMMDD}-{HHMMSS} - ELSE:
tdd-session-{YYYYMMDD}-{HHMMSS}
Clean stale live session: Follow the same procedure as execute-tasks:
- Check if
.claude/sessions/__live_session__/contains leftover files - If found, archive to
.claude/sessions/interrupted-{YYYYMMDD}-{HHMMSS}/ - Reset any
in_progresstasks from the interrupted session topending
Concurrency guard: Check for .claude/sessions/__live_session__/.lock. Follow the same lock protocol as execute-tasks.
Create session files in .claude/sessions/__live_session__/:
execution_plan.md-- Save the TDD execution plan from Step 5execution_context.md-- Initialize with TDD-extended template:markdown# Execution Context ## Project Patterns <!-- Discovered coding patterns, conventions, tech stack details --> ## Key Decisions <!-- Architecture decisions, approach choices made during execution --> ## Known Issues <!-- Problems encountered, workarounds applied, things to watch out for --> ## File Map <!-- Important files discovered and their purposes --> ## TDD Compliance | Task Pair | Test Task | Impl Task | RED | GREEN | Refactored | Coverage Delta | |-----------|-----------|-----------|-----|-------|------------|----------------| ## Task History <!-- Brief log of task outcomes with relevant context -->task_log.md-- Initialize with standard table headers:markdown# Task Execution Log | Task ID | Subject | Type | Status | Attempts | Duration | Token Usage | |---------|---------|------|--------|----------|----------|-------------|tasks/-- Empty subdirectory for archiving completed task filesprogress.md-- Initialize with status template:markdown# Execution Progress (TDD Mode) Status: Initializing Wave: 0 of {total_waves} Max Parallel: {max_parallel} TDD Strictness: {strictness} Updated: {ISO 8601 timestamp} ## Active Tasks ## Completed This Sessionexecution_pointer.mdat$HOME/.claude/tasks/{CLAUDE_CODE_TASK_LIST_ID}/execution_pointer.md-- Absolute path to.claude/sessions/__live_session__/
Step 7: Initialize Execution Context
Read .claude/sessions/__live_session__/execution_context.md (created in Step 6).
If a prior execution session's context exists, look in .claude/sessions/ for the most recent timestamped subfolder and merge relevant learnings (Project Patterns, Key Decisions, Known Issues, File Map) into the new execution context.
Context compaction: If Task History has 10+ entries from merged sessions, compact older entries into a summary paragraph and keep the 5 most recent in full.
Step 8: Execute Loop
Execute tasks in waves with TDD-aware agent routing. No user interaction between waves.
8a: Initialize Wave
- Identify all unblocked tasks (pending status, all dependencies completed)
- Sort by priority (critical > high > medium > low > unprioritized)
- Take up to
max_paralleltasks for this wave - If no unblocked tasks remain, exit the loop
8b: Snapshot Execution Context
Read .claude/sessions/__live_session__/execution_context.md and hold as baseline for this wave. All agents read from the same snapshot.
8c: Launch Wave Agents
- Mark all wave tasks as
in_progressviaTaskUpdate - Record
wave_start_time - Update
progress.mdwith active tasks - Launch all wave agents simultaneously using parallel Task tool calls in a single message turn
Route each task to the correct agent:
For TDD tasks (metadata.tdd_mode == true), launch the tdd-executor agent from tdd-tools:
Task:
subagent_type: tdd-executor
mode: bypassPermissions
prompt: |
Execute the following TDD task.
Task ID: {id}
Task Subject: {subject}
Task Description:
---
{full description}
---
Task Metadata:
- Priority: {priority}
- Complexity: {complexity}
- TDD Phase: {tdd_phase}
- Paired Task ID: {paired_task_id}
- TDD Strictness: {strictness}
CONCURRENT EXECUTION MODE
Context Write Path: .claude/sessions/__live_session__/context-task-{id}.md
Do NOT write to execution_context.md directly.
Do NOT update progress.md -- the orchestrator manages it.
Write your learnings to the Context Write Path above instead.
{If GREEN phase, include paired test task output:}
PAIRED TEST TASK OUTPUT:
---
{test task verification report and context}
---
The tests written by the paired test task are already on disk.
Your job is to implement code that makes these tests pass (GREEN phase),
then refactor while keeping tests green (REFACTOR phase).
{If retry attempt:}
RETRY ATTEMPT {n} of {max_retries}
Previous TDD phase that failed: {RED|GREEN|REFACTOR}
Previous attempt failed with:
---
{previous verification report including TDD COMPLIANCE section}
---
TDD-specific retry guidance:
- If RED failed (tests cannot run): Check test syntax, imports, and framework config
- If RED warned (tests passed unexpectedly): Verify tests target new behavior, not existing code
- If GREEN failed (tests still failing): Re-read test assertions, try different implementation approach
- If GREEN failed (regressions): Identify regression cause, fix without breaking new tests
- If REFACTOR failed: Revert to pre-refactor state, try smaller refactoring steps
Instructions (follow in order):
1. Read the TDD execution and verification references
2. Read .claude/sessions/__live_session__/execution_context.md for prior learnings
3. Understand the task requirements and explore the codebase
4. Execute the 6-phase TDD workflow (Understand, Write Tests, RED, Implement, GREEN, Complete)
5. Verify TDD compliance (RED verified, GREEN verified, refactored)
6. Update task status if PASS (mark completed)
7. Write learnings to .claude/sessions/__live_session__/context-task-{id}.md
8. Return a structured verification report including TDD COMPLIANCE section
9. Report any token/usage information available from your session
For non-TDD tasks (no tdd_mode metadata), launch the standard task-executor agent from sdd-tools:
Task:
subagent_type: task-executor
mode: bypassPermissions
prompt: |
Execute the following task.
Task ID: {id}
Task Subject: {subject}
Task Description:
---
{full description}
---
Task Metadata:
- Priority: {priority}
- Complexity: {complexity}
- Source Section: {source_section}
CONCURRENT EXECUTION MODE
Context Write Path: .claude/sessions/__live_session__/context-task-{id}.md
Do NOT write to execution_context.md directly.
Do NOT update progress.md -- the orchestrator manages it.
Write your learnings to the Context Write Path above instead.
{If retry attempt:}
RETRY ATTEMPT {n} of {max_retries}
Previous attempt failed with:
---
{previous verification report}
---
Focus on fixing the specific failures listed above.
Instructions (follow in order):
1. Read the execute-tasks skill and reference files
2. Read .claude/sessions/__live_session__/execution_context.md for prior learnings
3. Understand the task requirements and explore the codebase
4. Implement the necessary changes
5. Verify against acceptance criteria
6. Update task status if PASS (mark completed)
7. Write learnings to .claude/sessions/__live_session__/context-task-{id}.md
8. Return a structured verification report
9. Report any token/usage information available from your session
Important: Always include the CONCURRENT EXECUTION MODE section regardless of max_parallel value. All agents write to per-task context files.
8d: Process Results
As each agent returns:
- Calculate
duration(format: <60s ={s}s, <60m ={m}m {s}s, >=60m ={h}h {m}m {s}s) - Capture token usage from Task tool response if available
- Determine task type label:
TDD/RED,TDD/GREEN, ornon-TDD - Update
task_log.mdusing read-modify-write (append row):| {id} | {subject} | {TDD/RED|TDD/GREEN|non-TDD} | {PASS/PARTIAL/FAIL} | {attempt}/{max} | {duration} | {tokens or N/A} | - Log status:
[{id}] {subject}: {PASS|PARTIAL|FAIL} ({type}) - Update
progress.md: move task from Active to Completed - For TDD tasks: Extract TDD compliance data from the agent's report and update the
## TDD Compliancetable inexecution_context.md
Context append fallback: If the agent's report contains a LEARNINGS: section, write those learnings to context-task-{id}.md on behalf of the agent.
8e: Within-Wave Retry
After processing a failed result:
- Check retry count for the failed task
- If retries remaining:
- Re-launch the agent immediately with failure context (include previous report)
- For TDD tasks, include TDD-specific retry guidance in the prompt
- Update
progress.md:- [{id}] {subject} -- Retrying ({n}/{max})
- If retries exhausted:
- Leave task as
in_progress - Log final failure
- For TDD test tasks: The paired implementation task remains blocked and will not execute
- Leave task as
Test-writer agent failure fallback: If a TDD test task (RED phase) fails after all retries, the paired implementation task remains blocked. Do NOT fall back to running implementation without tests -- this would violate TDD principles.
8f: Merge Context After Wave
After ALL agents in the current wave have completed (including retries):
- Read
.claude/sessions/__live_session__/execution_context.md - Read all
context-task-{id}.mdfiles in task ID order - Append each file's content to the
## Task Historysection - For completed TDD tasks: Update the
## TDD Compliancetable with pair results - Write the complete updated
execution_context.md - Delete the
context-task-{id}.mdfiles
Capture test task output for GREEN phase injection: When processing a completed test task (RED phase), store its verification report for injection into the paired implementation task's prompt in the next wave.
8g: Rebuild Next Wave and Archive
- Archive completed task files to
.claude/sessions/__live_session__/tasks/ - Refresh task list via
TaskList - Check for newly unblocked tasks (especially implementation tasks unblocked by their paired test tasks)
- Form next wave using priority sort
- If no unblocked tasks remain, exit the loop
- Loop back to 8a
Step 9: Session Summary
Write final progress.md with complete status. Display the TDD execution summary:
TDD EXECUTION SUMMARY
Tasks executed: {total attempted}
TDD Pairs: {pair_count}
Non-TDD: {non_tdd_count}
Passed: {count}
Partial: {count}
Failed: {count} (after {total retries} total retry attempts)
TDD COMPLIANCE:
| Task Pair | Test Task | Impl Task | RED | GREEN | Refactored | Coverage Delta |
|-----------|-----------|-----------|-----|-------|------------|----------------|
| {feature} | #{test_id} ({status}) | #{impl_id} ({status}) | {Yes/No} | {Yes/No} | {Yes/No/N/A} | {+/-pct or N/A} |
...
TDD Compliance Rate: {compliant_pairs}/{total_pairs} ({percentage}%)
Waves completed: {wave_count}
Max parallel: {max_parallel}
TDD Strictness: {strictness}
Total execution time: {total_duration}
Token Usage: {total tokens or N/A}
Remaining:
Pending: {count}
In Progress (failed): {count}
Blocked: {count}
{If any tasks failed:}
FAILED TASKS:
[{id}] {subject} -- {brief failure reason} ({TDD phase if applicable})
{If newly unblocked tasks were discovered:}
NEWLY UNBLOCKED:
[{id}] {subject} -- unblocked by completion of [{blocker_id}]
After displaying the summary:
- Save
session_summary.mdto.claude/sessions/__live_session__/with full summary content - Archive the session: move all contents from
__live_session__/to.claude/sessions/{task_execution_id}/ - Leave
__live_session__/as an empty directory execution_pointer.mdstays pointing to__live_session__/
Step 10: Update CLAUDE.md
Review .claude/sessions/{task_execution_id}/execution_context.md for project-wide changes.
Update CLAUDE.md if the session introduced:
- New architectural patterns or conventions
- New dependencies or tech stack changes
- New development commands or workflows
- Changes to project structure
- Important design decisions
Skip if only task-specific or TDD-internal implementation details.
Agent Routing Summary
| Task Type | Detection | Agent | Plugin | Workflow |
|---|---|---|---|---|
| TDD test (RED) | tdd_mode: true, tdd_phase: "red" |
tdd-executor |
tdd-tools | 6-phase TDD |
| TDD impl (GREEN) | tdd_mode: true, tdd_phase: "green" |
tdd-executor |
tdd-tools | 6-phase TDD |
| Non-TDD | No tdd_mode or tdd_mode: false |
task-executor |
sdd-tools | 4-phase standard |
TDD Verification Rules
See references/tdd-verification-patterns.md for complete verification rules.
Quick reference:
| Phase | PASS | FAIL |
|---|---|---|
| RED | All new tests fail as expected | Tests cannot run or syntax errors |
| GREEN | All tests pass, zero regressions | New tests still failing after implementation |
| REFACTOR | All tests green after cleanup | Tests broke and cannot recover |
Strictness levels (from .claude/agent-alchemy.local.md tdd.strictness setting):
| Level | RED Behavior | Impact |
|---|---|---|
| strict | Tests passing unexpectedly = FAIL | Blocks GREEN phase |
| normal (default) | Tests passing unexpectedly = WARN | Proceeds with warning |
| relaxed | Tests passing unexpectedly = INFO | Proceeds, informational only |
Key Behaviors
- Autonomous execution loop: After user confirms the plan, no further prompts between tasks
- Wave-based TDD parallelism: Test tasks (RED) in one wave, their paired implementation tasks (GREEN) in the next. Multiple features run in parallel within a wave
- Agent routing by metadata: TDD tasks go to
tdd-executor, non-TDD tasks go totask-executor - Per-task context isolation: Each agent writes to
context-task-{id}.md, orchestrator merges after each wave - Test-to-implementation context flow: Test task output is injected into the paired implementation task's prompt via
PAIRED TEST TASK OUTPUT - Within-wave retry: Failed tasks with retries remaining re-launch immediately
- No silent degradation: If TDD test task fails, its paired implementation task stays blocked. Never run implementation without tests
- TDD compliance tracking: Per-pair tracking of RED/GREEN/REFACTOR verification in execution context
- Configurable strictness:
strict,normal, orrelaxedTDD enforcement via settings - Single-session invariant: Only one execution session at a time, enforced by
.lockfile - Interrupted session recovery: Stale sessions archived, interrupted tasks reset to
pending
Example Usage
Execute all TDD tasks
/agent-alchemy-sdd:execute-tdd-tasks
Execute TDD tasks for a specific group
/agent-alchemy-sdd:execute-tdd-tasks --task-group user-authentication
Execute with limited parallelism
/agent-alchemy-sdd:execute-tdd-tasks --max-parallel 2
Execute sequentially (no concurrency)
/agent-alchemy-sdd:execute-tdd-tasks --max-parallel 1
Execute with custom retries
/agent-alchemy-sdd:execute-tdd-tasks --retries 1
Execute group with custom parallelism and retries
/agent-alchemy-sdd:execute-tdd-tasks --task-group payments --max-parallel 3 --retries 1
Reference Files
references/tdd-execution-workflow.md-- TDD-aware wave execution, agent spawning, context sharing between RED and GREEN phasesreferences/tdd-verification-patterns.md-- RED/GREEN/REFACTOR verification rules, compliance reporting, status determination matrix
Recommended Agent Skills
Expand your agent's capabilities with these related and highly-rated skills.
agent-ops-spec
Manage specification documents in .agent/specs/. Use when user provides requirements, acceptance criteria, or feature descriptions that need to be tracked and validated against implementation.
agent-ops-state
Maintain .agent state files. Use at session start, after meaningful steps, and before concluding: read/update constitution/memory/focus/issues/baseline consistently.
agent-ops-spec
Manage specification documents in .agent/specs/. Use when user provides requirements, acceptance criteria, or feature descriptions that need to be tracked and validated against implementation.
agent-ops-testing
Test strategy, execution, and coverage analysis. Use when designing tests, running test suites, or analyzing test results beyond baseline checks.
agent-ops-testing
Test strategy, execution, and coverage analysis. Use when designing tests, running test suites, or analyzing test results beyond baseline checks.
agent-ops-state
Maintain .agent state files. Use at session start, after meaningful steps, and before concluding: read/update constitution/memory/focus/issues/baseline consistently.
Didn't find tool you were looking for?