---

name: task-planning description: Generates phased, dependency-ordered implementation tasks from specifications. Use after spec is complete and before starting implementation. alwaysApply: false category: planning tags:

• speckit
• tasks
• planning
• implementation
• dependencies dependencies:
• superpowers:writing-plans
• superpowers:executing-plans tools: [] modules:
• phase-structure.md
• dependency-patterns.md
• modules/tech-stack-patterns.md progressive_loading: true usage_patterns:
• task-generation
• dependency-ordering
• implementation-planning complexity: intermediate model_hint: standard estimated_tokens: 1200

---

Task Planning

Overview

Transforms specifications and implementation plans into concrete, dependency-ordered tasks. Creates phased breakdowns that guide systematic implementation.

When To Use

• Converting specifications to implementation tasks
• Planning feature implementation order
• Identifying parallel execution opportunities
• Breaking down complex features into phases

When NOT To Use

• Writing specifications - use spec-writing

Task Phases

Tasks follow a 5-phase structure from setup through polish:

• Phase 0: Setup - Project initialization, dependencies, configuration
• Phase 1: Foundation - Data models, interfaces, test infrastructure
• Phase 2: Core Implementation - Business logic, APIs, services
• Phase 3: Integration - External services, middleware, logging
• Phase 4: Polish - Optimization, documentation, final testing

For detailed phase definitions, selection guidelines, and anti-patterns, see modules/phase-structure.md.

Task Format

Each task includes:

• ID: Unique identifier (TASK-001)
• Description: Clear action statement
• Phase: Which phase it belongs to
• Dependencies: Tasks that must complete first
• Parallel Marker: [P] if can run concurrently
• Files: Affected file paths
• Criteria: How to verify completion

Dependency Rules

Dependencies define execution order and identify parallelization opportunities:

• Sequential Tasks: Execute in strict order when dependencies exist
• Parallel Tasks [P]: Can run concurrently when ALL nonconflicting conditions are met
• File Coordination: Tasks affecting same files MUST run sequentially

Nonconflicting Criteria for Parallel Execution:

• ✅ Files: No file overlap between tasks
• ✅ State: No shared configuration or global state
• ✅ Dependencies: All prerequisites satisfied
• ✅ Code paths: No merge conflicts possible
• ✅ Outputs: Tasks don't need each other's results

Mark tasks with [P] ONLY if they pass ALL criteria above.

For fan-out/fan-in patterns, task ID conventions, and validation rules, see modules/dependency-patterns.md.

Example Task Entry

## Phase 2: Core Implementation

### TASK-007 - Implement user authentication service [P]
**Dependencies**: TASK-003, TASK-004
**Files**: src/services/auth.ts, src/types/user.ts
**Criteria**: All auth tests pass, tokens are valid JWT

Verification: Run pytest -v to verify tests pass.

Quality Checklist

• All requirements mapped to tasks
• Dependencies are explicit
• Parallel opportunities identified
• Tasks are right-sized (not too large/small)
• Each task has clear completion criteria

Related Skills

• spec-writing: Creating source specifications
• speckit-orchestrator: Workflow coordination

Exit Criteria

• Every task has a unique ID in TASK-NNN format and includes Description, Phase (0-4), Dependencies list, Parallel marker ([P] or sequential), Files, and Criteria fields
• Tasks marked [P] pass all 5 nonconflicting criteria: no file overlap, no shared state, dependencies satisfied, no merge conflicts possible, no output dependency on each other
• Every functional requirement from the source spec is mapped to at least one task; unmapped requirements are flagged
• Quality checklist passes all items before output is finalized
• Tasks within each phase are ordered so that no task depends on one with a higher task number within the same phase