Generate Implementation Tasks

You are converting an implementation plan into an actionable, dependency-ordered task list. Tasks MUST be organized by user story to enable independent implementation and testing.

Upstream source: github/spec-kit

Prerequisites

• A feature plan must exist at specs/[###-feature-name]/plan.md
• A feature spec must exist at specs/[###-feature-name]/spec.md

If these don't exist, instruct the user to run /spec-kit:plan first.

Workflow

Step 1: Identify the Feature

• If the user specifies a feature name/number, locate it in specs/
• If multiple features exist and none is specified, list available features and ask the user to choose
• If only one feature exists, use it automatically

Step 2: Load Context

Read all available design artifacts:

• specs/[###-feature]/plan.md (required — tech stack, libraries, project structure)
• specs/[###-feature]/spec.md (required — user stories with priorities)
• specs/[###-feature]/data-model.md (if exists — entities to map to user stories)
• specs/[###-feature]/contracts/ (if exists — interface contracts to map to user stories)
• specs/[###-feature]/research.md (if exists — decisions for setup tasks)

Step 3: Task Generation

CRITICAL: Tasks must be organized by user story. Each user story gets its own phase that can be independently implemented and tested.

Tests are OPTIONAL: Only generate test tasks if explicitly requested in the feature specification or if the user asks for TDD approach.

Checklist format (every task MUST follow this exactly):

- [ ] T### [P?] [US#?] Description with file path

Format components:

1. - [ ] — Always start with checkbox
2. T### — Sequential task ID (T001, T002, T003...)
3. [P] — Include ONLY if task is parallelizable (different files, no incomplete dependencies)
4. [US#] — Required for user story phase tasks only (US1, US2, US3... matching spec user story numbers)
5. Description — Clear action with exact file path

Examples:

• ✅ - [ ] T001 Create project structure per implementation plan
• ✅ - [ ] T005 [P] Implement authentication middleware in src/middleware/auth.py
• ✅ - [ ] T012 [P] [US1] Create User model in src/models/user.py
• ✅ - [ ] T014 [US1] Implement UserService in src/services/user_service.py
• ❌ - [ ] Create User model (missing ID, Story label, file path)
• ❌ T001 [US1] Create model (missing checkbox)

Generate specs/[###-feature]/tasks.md following this structure:

# Implementation Tasks: [FEATURE NAME]

**Branch**: `[###-feature-name]` | **Date**: [TODAY]
**Spec**: spec.md | **Plan**: plan.md

## Phase 1: Setup (Shared Infrastructure)

**Purpose**: Project initialization and basic structure

- [ ] T001 Create project structure per implementation plan
- [ ] T002 Initialize [language] project with [framework] dependencies
- [ ] T003 [P] Configure linting and formatting tools

---

## Phase 2: Foundational (Blocking Prerequisites)

**Purpose**: Core infrastructure that MUST be complete before ANY user story

**⚠️ CRITICAL**: No user story work can begin until this phase is complete

- [ ] T004 Setup database schema and migrations framework
- [ ] T005 [P] Implement authentication/authorization framework
- [ ] T006 [P] Setup API routing and middleware structure
- [ ] T007 Create base models/entities that all stories depend on

**Checkpoint**: Foundation ready — user story implementation can now begin in parallel

---

## Phase 3: User Story 1 - [Title] (Priority: P1) 🎯 MVP

**Goal**: [Brief description of what this story delivers]

**Independent Test**: [How to verify this story works on its own]

### Tests for User Story 1 (OPTIONAL — only if tests requested) ⚠️

> **NOTE: Write these tests FIRST, ensure they FAIL before implementation**

- [ ] T008 [P] [US1] Contract test for [endpoint] in tests/contract/test_[name].[ext]
- [ ] T009 [P] [US1] Integration test for [user journey] in tests/integration/test_[name].[ext]

### Implementation for User Story 1

- [ ] T010 [P] [US1] Create [Entity] model in src/models/[entity].[ext]
- [ ] T011 [US1] Implement [Service] in src/services/[service].[ext]
- [ ] T012 [US1] Implement [feature] in src/[location]/[file].[ext]
- [ ] T013 [US1] Add validation and error handling

**Checkpoint**: User Story 1 is fully functional and independently testable

---

## Phase 4: User Story 2 - [Title] (Priority: P2)

**Goal**: [Brief description]

**Independent Test**: [How to verify independently]

- [ ] T014 [P] [US2] Create [Entity] model in src/models/[entity].[ext]
- [ ] T015 [US2] Implement [Service] in src/services/[service].[ext]
- [ ] T016 [US2] Implement [feature] in src/[location]/[file].[ext]

**Checkpoint**: User Stories 1 AND 2 both work independently

---

[Add more user story phases following the same pattern]

---

## Phase N: Polish & Cross-Cutting Concerns

**Purpose**: Improvements that affect multiple user stories

- [ ] TXXX [P] Documentation updates in docs/
- [ ] TXXX Code cleanup and refactoring
- [ ] TXXX Performance optimization
- [ ] TXXX Security hardening

---

## Dependencies & Execution Order

### Phase Dependencies

- **Setup (Phase 1)**: No dependencies — can start immediately
- **Foundational (Phase 2)**: Depends on Setup — BLOCKS all user stories
- **User Stories (Phase 3+)**: All depend on Foundational; can proceed in parallel (if staffed) or sequentially (P1 → P2 → P3)
- **Polish (Final Phase)**: Depends on all desired user stories being complete

### Parallel Opportunities

- All Setup tasks marked [P] can run in parallel
- Once Foundational is complete, all user stories can start in parallel (if team capacity allows)
- Models within a story marked [P] can run in parallel

---

## Implementation Strategy

### MVP First (User Story 1 Only)

1. Complete Phase 1: Setup
2. Complete Phase 2: Foundational (CRITICAL — blocks all stories)
3. Complete Phase 3: User Story 1
4. **STOP and VALIDATE**: Test User Story 1 independently
5. Deploy/demo if ready

### Incremental Delivery

- Setup + Foundational → Foundation ready
- Add User Story 1 → Test independently → Deploy/Demo (MVP!)
- Add User Story 2 → Test independently → Deploy/Demo
- Each story adds value without breaking previous stories

---

**Legend**: `[P]` = parallelizable | `[US#]` = user story reference | `[T###]` = sequential task ID

Step 4: Validate Task Coverage

After generating the task list, verify:

1. Every functional requirement (FR-###) from spec.md is covered by at least one task
2. Every user story has implementation tasks (and tests if TDD requested)
3. No circular dependencies exist
4. [P] tasks truly have no interdependencies
5. Each user story phase is independently completable and testable

Step 5: Output Summary

Task List Generated: specs/[###-feature-name]/tasks.md

  Total Tasks: [count]
  Phases: [count]
  Parallelizable: [count] tasks marked [P]

  Breakdown by Story:
    Setup:           [count] tasks
    Foundational:    [count] tasks
    US1 (P1) - MVP:  [count] tasks
    US2 (P2):        [count] tasks
    US3 (P3):        [count] tasks
    Polish:          [count] tasks

  Independent Test Criteria:
    US1: [How to verify independently]
    US2: [How to verify independently]
    US3: [How to verify independently]

  Suggested MVP Scope: User Story 1 only (Phases 1-3)

Next step:
  - Run /spec-kit:analyze first to verify cross-artifact consistency
  - Then run /spec-kit:implement to start executing the tasks

Important Rules

• Tasks are a technical artifact — they CAN and SHOULD reference specific files and technologies.
• Every functional requirement (FR-###) must be covered by at least one task.
• Tasks must be specific enough that an agent can complete without asking questions.
• Include the target file path whenever a task involves creating or modifying a file.
• Each user story's tasks should be independently deliverable as an MVP increment.
• The task list must be complete — executing all tasks fully implements the feature.