---
description: Execute spec tasks using TDD methodology
allowed-tools: Bash, Read, Write, Edit, MultiEdit, Grep, Glob, LS, WebFetch, WebSearch
argument-hint: <feature-name> [task-numbers]
---

# Implementation Task Executor

<background_information>
- **Role**: Drive implementation of approved specification tasks following Test-Driven Development discipline, producing tested, regression-free code that conforms to the design.
- **Success Criteria**:
  - Tests are authored and verified to fail before any implementation code is written
  - All new code passes its tests with no regressions in existing functionality
  - Completed tasks are marked done in `tasks.md`
  - The implementation faithfully reflects the contracts and structure defined in `design.md`
</background_information>

<instructions>
## Core Task
Execute the implementation tasks for feature **$1** using Test-Driven Development.

## Execution Steps

### Step 1: Load Context

**Read all required inputs**:
- `{{SDD_DIR}}/specs/$1/spec.json`, `requirements.md`, `design.md`, `tasks.md`
- The entire `{{SDD_DIR}}/steering/` directory (core + all custom files) for complete project memory

**Verify approvals**:
- Confirm tasks are approved in `spec.json` — halt if not (see Safety & Fallback)

### Step 2: Determine Scope

**Select which tasks to execute**:
- If `$2` is provided: execute the specified task numbers only (e.g., `"1.1"` or `"1,2,3"`)
- If `$2` is absent: execute all pending tasks (every unchecked `- [ ]` item in `tasks.md`)

### Step 3: Execute with TDD

For each selected task, apply Kent Beck's Red–Green–Refactor cycle rigorously:

**1. RED — Write a Failing Test**
- Author a test that specifies the next small, discrete unit of behavior
- Run the test to confirm it fails (the implementation does not yet exist)
- Use descriptive test names that read as specifications

**2. GREEN — Write Minimal Implementation**
- Write the simplest code that makes the failing test pass
- Resist the urge to solve more than this one test requires
- No premature abstractions or over-engineering at this step

**3. REFACTOR — Improve the Code**
- Eliminate duplication and improve readability and structure
- Apply design patterns only where they genuinely clarify intent
- Rerun all tests to confirm nothing was broken by the cleanup

**4. VERIFY — Confirm Quality**
- All tests pass, including the full pre-existing suite
- No regressions detected in unrelated functionality
- Code coverage is maintained or improved

**5. MARK COMPLETE**
- Update the task checkbox from `- [ ]` to `- [x]` in `tasks.md`

## Critical Constraints
- **TDD is non-negotiable**: Tests must be written before implementation code — no exceptions
- **Task scope discipline**: Implement only what the current task explicitly requires
- **Test coverage required**: Every new code path must have a corresponding test
- **Zero regressions**: The existing test suite must continue to pass throughout
- **Design fidelity**: The implementation must reflect the interfaces and structure in `design.md`
</instructions>

## Tool Guidance
- **Read first**: Load all spec context and steering before writing any code
- **Test first**: Write the test file before the implementation file
- Use **WebSearch/WebFetch** when library documentation or external API references are needed

## Output Description

Report in the language specified in `spec.json`:

1. **Tasks Executed**: List task numbers along with a pass/fail summary for associated tests
2. **Progress Update**: Count of tasks now marked complete versus remaining open items

**Format**: Under 150 words

## Safety & Fallback

### Error Scenarios

**Tasks Not Approved or Spec Files Missing**:
- **Halt**: All spec documents must exist and tasks must be approved before implementation begins
- **Suggested Action**: "Complete all prior phases — `/sdd:spec-requirements`, `/sdd:spec-design`, `/sdd:spec-tasks` — before running implementation"

**Test Failures**:
- **Halt Implementation**: Do not proceed to the next task while any test is failing
- **Action**: Diagnose the failure, fix the issue, and rerun the test before continuing

### Execution Reference

**Run a single task**:
```
/sdd:spec-impl $1 1.1
```

**Run multiple tasks**:
```
/sdd:spec-impl $1 1,2,3
```

**Run all pending tasks** (not recommended — may exhaust context):
```
/sdd:spec-impl $1
```

think
