---
description: Generate implementation tasks for a specification
allowed-tools: Read, Write, Edit, MultiEdit, Glob, Grep
argument-hint: <feature-name> [-y] [--sequential]
---

# Implementation Tasks Generator

<background_information>
- **Role**: Decompose the approved technical design into a structured, executable task list that developers can implement incrementally.
- **Success Criteria**:
  - Every requirement has at least one corresponding task
  - Tasks are scoped to 1–3 hours of sub-task work and progress logically
  - Parallel execution opportunities are identified where safe
  - The task list serves as a living progress tracker throughout implementation
</background_information>

<instructions>
## Core Task
Produce the implementation task list for feature **$1** based on its approved requirements and design.

## Execution Steps

### Step 1: Load Context

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

**Gate on approvals**:
- If `-y` is provided ($2 == "-y"): auto-approve requirements and design in `spec.json` and continue
- Otherwise: confirm both are approved — halt if either is missing approval (see Safety & Fallback)
- Detect sequential mode: if `--sequential` is in the arguments, omit `(P)` markers throughout

### Step 2: Generate the Task List

**Load the required rules and template**:
- Read `{{SDD_DIR}}/settings/rules/tasks-generation.md` for all authoring principles
- If sequential mode is **not** active: read `{{SDD_DIR}}/settings/rules/tasks-parallel-analysis.md` for parallel identification criteria
- Read `{{SDD_DIR}}/settings/templates/specs/tasks.md` for the exact checkbox and formatting conventions

**Author the task list following all rules**:
- Write in the language specified in `spec.json`
- Ensure every requirement from `requirements.md` maps to at least one task
- When recording requirement coverage, list only numeric IDs (comma-separated) — no descriptions, translations, parenthetical notes, or free-form labels
- Confirm all design components are represented in the task breakdown
- Validate that task ordering is logical and incremental — earlier tasks should not depend on later ones
- Collapse single-subtask structures: if a major task would contain only one sub-task, promote the sub-task to the major level
- Avoid duplicating content on container-only major tasks; reserve detail bullets for sub-tasks
- Apply `(P)` markers to tasks that meet all parallel criteria; omit entirely in sequential mode
- Mark purely deferrable test coverage sub-tasks with `- [ ]*` only when they directly address acceptance criteria and implementation coverage is already ensured by core work
- If a prior `tasks.md` exists, merge new tasks with existing content rather than replacing

### Step 3: Finalize

**Write and update**:
- Create or overwrite `{{SDD_DIR}}/specs/$1/tasks.md`
- Update `spec.json` metadata:
  - Set `phase: "tasks-generated"`
  - Set `approvals.tasks.generated: true` and `approvals.tasks.approved: false`
  - Set `approvals.requirements.approved: true` and `approvals.design.approved: true`
  - Refresh `updated_at` timestamp

## Critical Constraints
- **All rules are mandatory**: Every principle in `tasks-generation.md` applies without exception
- **Functional language**: Describe what to accomplish, not code structure or file names
- **Full requirements coverage**: No requirement may be left without a corresponding task
- **Two levels maximum**: Major tasks (1, 2, 3...) and sub-tasks (1.1, 1.2, 2.1...) — no deeper nesting
- **Sequential major numbering**: Major task numbers must increment and never repeat
- **System integration**: Every task must connect to the overall system — no orphaned work items
</instructions>

## Tool Guidance
- **Read first**: Load all context, generation rules, and templates before beginning
- **Write last**: Produce `tasks.md` only after analysis and coverage verification are complete

## Output Description

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

1. **Status**: Confirm task list generated at `{{SDD_DIR}}/specs/$1/tasks.md`
2. **Task Breakdown**:
   - Total major tasks and sub-tasks
   - Number of requirements covered
   - Estimated sub-task size range (target: 1–3 hours each)
3. **Quality Checks**:
   - All requirements mapped
   - Task dependencies verified
   - Test tasks included
4. **Next Action**: Instruct the user on reviewing and proceeding

**Format**: Under 200 words

## Safety & Fallback

### Error Scenarios

**Requirements or Design Not Approved**:
- **Halt**: Task generation requires both approvals
- **Message**: "Both requirements and design must be approved before task generation"
- **Suggested Action**: "Run `/sdd:spec-tasks $1 -y` to auto-approve both and proceed"

**Requirements or Design Document Missing**:
- **Halt**: Both documents must exist
- **Message**: "Missing `requirements.md` or `design.md` at `{{SDD_DIR}}/specs/$1/`"
- **Suggested Action**: "Complete the requirements and design phases first"

**Incomplete Requirements Coverage**:
- **Warning**: "One or more requirements are not mapped to any task — review coverage"
- **User Decision Required**: Confirm the gap is intentional or regenerate the task list

**Template or Rules Missing**:
- **Message**: "Template or rules files not found under `{{SDD_DIR}}/settings/`"
- **Fallback**: Apply an inline basic structure with a visible warning
- **Suggested Action**: "Check repository setup or restore the missing files"

**Non-Numeric Requirement IDs**:
- **Halt**: If any requirement in `requirements.md` lacks a numeric ID, stop and ask the user to correct `requirements.md` before proceeding

### Next Phase: Implementation

**Before Starting Implementation**:
- Clear conversation history to free context before running `/sdd:spec-impl`
- This applies when beginning the first task or switching between tasks
- A fresh context window ensures clean state and proper task focus

**When Tasks Are Approved**:
- Single task: `/sdd:spec-impl $1 1.1`
- Multiple tasks: `/sdd:spec-impl $1 1.1,1.2` (use with caution; clear context between runs)
- All pending: `/sdd:spec-impl $1` (not recommended — risks context bloat)

**When Changes Are Needed**:
- Provide specific feedback and re-run `/sdd:spec-tasks $1`
- Existing tasks will be used as merge reference

**Note**: Clear conversation context before each implementation run for best results.

think
