Spec Tasks

# Spec Tasks Command

Generate implementation task list based on approved design with MANDATORY Test-Driven Development.

## Usage

/spec-tasks [feature-name]

## Phase Overview
**Your Role**: Break design into executable TDD implementation tasks

This is Phase 3 of the spec workflow. Your goal is to create a detailed task breakdown that will guide the implementation of the feature using **MANDATORY Test-Driven Development (TDD)**. All tasks must include the five required TDD fields and will be automatically validated for compliance. Generated task commands will use TDD workflow templates with RED-GREEN-REFACTOR-VERIFY phases.

## Instructions
You are working on the tasks phase of the spec workflow.

**WORKFLOW**: This is the FINAL step before command generation.
**SEQUENCE**: Create Tasks → Get Approval → Ask User → Generate Commands
**DO NOT** run task command generation until tasks are approved.

1. **Prerequisites**
   - Ensure design.md exists and is approved in `.claude/specs/{feature-name}/`
   - Load both documents from the spec directory:
     - Load `.claude/specs/{feature-name}/requirements.md` for feature context
     - Load `.claude/specs/{feature-name}/design.md` for technical design
   - **Load steering documents** (if available):
     - Check for .claude/steering/structure.md for project conventions
     - Check for .claude/steering/tech.md for technical patterns
   - Understand the complete feature scope

2. **Process**
   1. Convert design into atomic, executable TDD coding tasks
   2. Ensure each task:
      - Has a clear, actionable objective
      - **INCLUDES ALL MANDATORY TDD FIELDS**: Test Specs, Test Location, Test Cases, Acceptance, Implementation
      - References specific requirements using _Requirements: X.Y_ format
      - Builds incrementally on previous tasks
      - Focuses on coding activities with test-first approach
      - Follows RED-GREEN-REFACTOR-VERIFY TDD workflow
   3. Use checkbox format with hierarchical numbering
   4. Present complete task list with TDD structure
   5. Ask: "Do the tasks look good?"
   6. **CRITICAL**: Wait for explicit approval before proceeding
   7. **TDD VALIDATION**: All tasks will be automatically validated for TDD compliance - missing TDD fields will cause errors
   8. **AFTER APPROVAL**: Ask "Would you like me to generate individual task commands for easier execution? (yes/no)"
   9. **IF YES**: Execute `uvx --from git+https://bitbucket.org/tunaiku/spec-workflow.git spec-driven-workflow generate-task-commands {feature-name}`
   10. **IF NO**: Continue with traditional `/spec-execute` approach
   11. **IMPORTANT**: Generated task commands will use TDD workflow templates with RED-GREEN-REFACTOR phases

3. **Generate Task List** (prioritize code reuse and follow conventions)
   - Break design into atomic, executable coding tasks
   - **Follow structure.md**: Ensure tasks respect project file organization
   - **Prioritize extending/adapting existing code** over building from scratch
   - Use checkbox format with numbered hierarchy
   - Each task should reference specific requirements AND existing code to leverage
   - Focus ONLY on coding tasks (no deployment, user testing, etc.)

4. **Task Guidelines**
   - Tasks should be concrete and actionable
   - **MANDATORY TDD COMPLIANCE**: Every task must include all five TDD fields (Test Specs, Test Location, Test Cases, Acceptance, Implementation)
   - **Test-First Approach**: Always design tests before implementation - follow RED-GREEN-REFACTOR-VERIFY cycle
   - **Reference existing code to reuse**: Include specific files/components to extend or adapt
   - Include specific file names and components  
   - Build incrementally (each task builds on previous)
   - Reference requirements using _Requirements: X.Y_ format
   - **TDD Workflow Integration**: Tasks will be validated for TDD compliance and use TDD command templates
   - **Unit Testing Focus**: Each task should represent a testable unit following the "smallest deliverable piece" principle

### Task Format
Use this exact TDD format for all tasks (all TDD fields are MANDATORY):

```markdown
- [ ] 1. Task description
  - **Test Specs**: What the tests should validate for this task
  - **Test Location**: `tests/test_module.py`
  - **Test Cases**:
    - Test successful scenario with valid inputs
    - Test error handling with invalid inputs
    - Test edge cases and boundary conditions
  - **Acceptance**: Clear criteria for when all tests pass and task is complete
  - **Implementation**: Brief approach for implementing to make tests pass
  - Detailed implementation steps and files to create/modify
  - _Requirements: 1.1, 2.3_
  - _Leverage: existing-component.ts, utils/helpers.js_

- [ ] 2. Another task description
  - **Test Specs**: What needs to be validated for task 2
  - **Test Location**: `tests/test_another_module.py`
  - **Test Cases**:
    - Test primary functionality
    - Test integration with task 1 components
  - **Acceptance**: All tests pass with expected behavior
  - **Implementation**: Use TDD approach - write tests first, then implement
  - Implementation details for this task
  - _Requirements: 2.1_

- [ ] 2.1 Subtask description
  - **Test Specs**: Specific validation requirements for subtask
  - **Test Location**: `tests/test_another_module.py`
  - **Test Cases**:
    - Test subtask specific behavior
  - **Acceptance**: Subtask tests pass and integrate with parent task
  - **Implementation**: Follow RED-GREEN-REFACTOR cycle
  - Subtask implementation details
  - _Requirements: 2.1_
  - _Leverage: shared/component.ts_

CRITICAL TDD Format Rules:

• Start with - [ ] (dash, space, left bracket, space, right bracket, space)
• Follow with task number and period: 1. or 2.1
• Add task description after the period and space
• MANDATORY TDD Fields (must be included for every task):
  • Test Specs: What the tests should validate
  • Test Location: Path to test file (e.g., `tests/