SDD Tasks Skill

When to Use

Activate this skill when:

•User invokes /tasks command
•User requests task list or work breakdown
•User asks "what do I need to implement?"
•Implementation plan is complete and ready for execution
•Need to break down plan into executable tasks

Trigger Keywords: tasks, task list, work breakdown, implementation steps, what to do next, /tasks

Prerequisites:

•Feature specification exists (from /specify)
•Implementation plan exists (from /plan)
•Design artifacts exist (research.md, data-model.md, contracts/, quickstart.md)

Procedure

Step 1: Check Prerequisites

Run prerequisite check script:

bash

.specify/scripts/bash/check-task-prerequisites.sh --json

Parse JSON output to extract:

•FEATURE_DIR: Directory containing all feature artifacts
•AVAILABLE_DOCS: List of available design documents

Available documents may include:

•plan.md (ALWAYS required)
•data-model.md (if entities defined)
•contracts/ (if APIs/interfaces defined)
•research.md (if technical research done)
•quickstart.md (if test scenarios defined)

IMPORTANT: Not all features have all documents. Generate tasks based on what's available.

Step 2: Load and Analyze Design Artifacts

Always read the implementation plan:

bash

Read: $FEATURE_DIR/plan.md

•Extract tech stack and libraries
•Understand implementation approach
•Identify architecture patterns

Read data-model.md if exists:

bash

Read: $FEATURE_DIR/data-model.md

•Extract entity names
•Understand relationships
•Note any special requirements

Read contracts/ directory if exists:

bash

Glob: $FEATURE_DIR/contracts/*.md
Read: [each contract file]

•Extract endpoint/interface names
•Understand request/response schemas
•Note error cases

Read research.md if exists:

bash

Read: $FEATURE_DIR/research.md

•Understand technical decisions
•Note dependencies and libraries
•Understand patterns to follow

Read quickstart.md if exists:

bash

Read: $FEATURE_DIR/quickstart.md

•Extract test scenarios
•Understand user stories
•Note integration test requirements

Step 3: Load Task Template

Read the task template:

bash

Read: .specify/templates/tasks-template.md

Template provides structure for:

•Task numbering (T001, T002, etc.)
•Task categories (Setup, Tests, Core, Integration, Polish)
•Parallel execution markers [P]
•Dependency tracking
•Progress tracking

Step 4: Generate Tasks by Category

Setup Tasks (always first):

code

T001: [ ] Initialize project structure
T002: [ ] Install and configure dependencies [from research.md]
T003: [ ] Set up linting and formatting [P]
T004: [ ] Configure build system [P]

Test Tasks (test-first, marked [P] for parallelism):

code

For each contract file:
  T00X: [ ] Write contract test for [endpoint/interface] [P]

For each user story in quickstart.md:
  T00Y: [ ] Write integration test for [user story] [P]

Core Implementation Tasks:

code

For each entity in data-model.md:
  T00Z: [ ] Implement [Entity] model [P]

For each contract:
  T00A: [ ] Implement [endpoint/interface]
  (NOT parallel if multiple endpoints share same file)

For each service/module in plan:
  T00B: [ ] Implement [Service] logic

Integration Tasks:

code

T00C: [ ] Set up database connection (if database domain)
T00D: [ ] Configure middleware and error handling
T00E: [ ] Set up logging and observability
T00F: [ ] Integrate with external services (if any)

Polish Tasks (final, marked [P]):

code

T00G: [ ] Add unit tests for edge cases [P]
T00H: [ ] Performance optimization [P]
T00I: [ ] Documentation generation [P]
T00J: [ ] Code review and refactoring [P]

Step 5: Apply Task Generation Rules

Parallel Execution Rules:

•Mark [P] if: Tasks work on different files
•No [P] if: Tasks modify same file (sequential required)

Examples:

code

✅ PARALLEL:
- T005: Write contract test for GET /users [P]
- T006: Write contract test for POST /users [P]
(Different test files)

❌ NOT PARALLEL:
- T010: Implement GET /users endpoint
- T011: Implement POST /users endpoint
(Same routes file)

Dependency Ordering:

•Setup tasks first
•Test tasks before implementation (TDD)
•Models before services
•Services before endpoints
•Core before integration
•Everything before polish

Step 6: Write Tasks File

Create task list:

bash

Write: $FEATURE_DIR/tasks.md

Include in tasks.md:

•Feature name and description
•Total task count
•Parallel execution guidance
•All tasks with numbers (T001, T002, etc.)
•Clear file paths for each task
•Dependency notes
•Progress tracking checkboxes

Task format:

markdown

- [ ] T001: Task description
  - File: `path/to/file.ts`
  - Dependencies: None
  - Parallel: No

- [ ] T005: Write contract test for GET /users [P]
  - File: `tests/contracts/get-users.test.ts`
  - Dependencies: T001, T002
  - Parallel: Yes (with T006, T007)

Step 7: Validate Task List

Run task validation:

bash

.specify/scripts/bash/validate-tasks.sh --file $FEATURE_DIR/tasks.md

Validation checks (12 total):

Task Quality (6 checks):

•Has tasks (at least 1)
•Has numbered tasks (T001, T002, etc.)
•Has parallel tasks marked [P]
•Tasks have clear descriptions
•Tasks have file paths
•Tasks have dependency notes

Constitutional Compliance (3 checks):

•Has test tasks (Principle II: Test-First)
•Has contract tasks (Principle III: Contract-First)
•Tests before implementation (TDD ordering)

Organization (3 checks):

•Tasks ordered by dependencies
•Setup tasks first
•Polish tasks last

Report validation results:

•Overall score (X/12 checks passing)
•Total task count
•Parallel task count
•Readiness status

Step 8: Domain Detection

Run domain detection on tasks:

bash

.specify/scripts/bash/detect-phase-domain.sh --file $FEATURE_DIR/tasks.md

Identify agents needed for task execution:

•Specialist agents by domain
•Delegation strategy (single vs multi-agent)
•task-orchestrator if multi-domain

Step 9: Report Completion

Provide comprehensive summary:

code

✅ Task List Generated

Task File: [path-to-tasks.md]

Task Statistics:
- Total Tasks: X
- Parallel Tasks: Y
- Sequential Tasks: Z
- Estimated Duration: [based on task count]

Validation Score: X/12
Status: [ready/needs-improvement]

Task Breakdown:
- Setup: A tasks
- Tests: B tasks (all parallel)
- Core Implementation: C tasks
- Integration: D tasks
- Polish: E tasks (all parallel)

Domains Detected: [list]
Suggested Agents: [list]
Delegation Strategy: [single-agent/multi-agent]

Constitutional Compliance:
✅ Test-First: Tests before implementation
✅ Contract-First: Contract tests included
✅ Dependency-Ordered: Correct task sequence

Parallel Execution Example:
  Run T005, T006, T007 together:
  - All write contract tests
  - Different files, no conflicts

Next Step: Execute tasks sequentially or delegate to specialized agents

Constitutional Compliance

Principle II: Test-First Development

•ALL test tasks BEFORE implementation tasks
•Contract tests first
•Integration tests early
•Unit tests for edge cases last
•No implementation without corresponding test

Principle III: Contract-First Design

•Contract test tasks for EACH contract file
•
Contract tests validate:
- •Request schema
- •Response schema
- •Error cases
•Contract tests marked [P] for parallel execution

Principle X: Agent Delegation Protocol

•Tasks identify which agents/domains are needed
•Multi-domain features routed to task-orchestrator
•Single-domain features routed to specialist
•Domain detection guides delegation

Examples

Example 1: REST API Task Generation

User Request: "/tasks Generate task list for user authentication API"

Available Artifacts:

•plan.md: Express.js API, bcrypt, JWT
•data-model.md: User entity, Session entity
•contracts/: POST /api/register, POST /api/login, POST /api/logout
•quickstart.md: Registration scenario, Login scenario, Logout scenario

Generated Tasks:

markdown

# User Authentication API - Tasks

Total: 18 tasks (8 parallel)

## Setup (4 tasks)
- [ ] T001: Initialize Express.js project structure
- [ ] T002: Install dependencies (express, bcrypt, jsonwebtoken, pg)
- [ ] T003: Set up ESLint and Prettier [P]
- [ ] T004: Configure TypeScript [P]

## Tests (6 tasks - all parallel)
- [ ] T005: Write contract test for POST /api/register [P]
- [ ] T006: Write contract test for POST /api/login [P]
- [ ] T007: Write contract test for POST /api/logout [P]
- [ ] T008: Write integration test for registration flow [P]
- [ ] T009: Write integration test for login flow [P]
- [ ] T010: Write integration test for logout flow [P]

## Core Implementation (5 tasks)
- [ ] T011: Implement User model
- [ ] T012: Implement Session model
- [ ] T013: Implement POST /api/register endpoint
- [ ] T014: Implement POST /api/login endpoint
- [ ] T015: Implement POST /api/logout endpoint

## Integration (2 tasks)
- [ ] T016: Set up PostgreSQL connection and migrations
- [ ] T017: Configure JWT middleware and error handling

## Polish (3 tasks - all parallel)
- [ ] T018: Add unit tests for password hashing [P]
- [ ] T019: Performance test for concurrent logins [P]
- [ ] T020: Generate API documentation [P]

Validation: 12/12 checks passing Domains: backend, database, security Agents: backend-architect, database-specialist, security-specialist Delegation: multi-agent via task-orchestrator

Example 2: React Component Task Generation

User Request: "/tasks Break down user profile card component"

Available Artifacts:

•plan.md: React 18, TypeScript, CSS Modules, Vitest
•data-model.md: UserProfile interface, Avatar interface
•contracts/: ProfileCard component props
•quickstart.md: Component rendering scenarios

Generated Tasks:

markdown

# User Profile Card Component - Tasks

Total: 12 tasks (6 parallel)

## Setup (3 tasks)
- [ ] T001: Initialize React component structure
- [ ] T002: Install dependencies (react, typescript, vitest)
- [ ] T003: Set up Vitest and React Testing Library [P]

## Tests (4 tasks - all parallel)
- [ ] T004: Write component prop validation test [P]
- [ ] T005: Write rendering test with mock data [P]
- [ ] T006: Write interaction test (click, hover) [P]
- [ ] T007: Write accessibility test (ARIA, keyboard) [P]

## Core Implementation (3 tasks)
- [ ] T008: Implement ProfileCard component structure
- [ ] T009: Implement Avatar sub-component
- [ ] T010: Style components with CSS Modules

## Polish (2 tasks - parallel)
- [ ] T011: Add Storybook stories [P]
- [ ] T012: Component documentation [P]

Validation: 11/12 checks passing (no integration tasks needed) Domains: frontend Agents: frontend-specialist Delegation: single-agent

Agent Collaboration

tasks-agent

When to delegate: Complex task breakdown, dependency analysis

What they handle: Creating task lists, identifying dependencies, task sequencing

task-orchestrator

When to delegate: Multi-domain tasks (3+ domains)

What they handle: Coordinating multiple specialists to execute tasks

Domain Specialists

When to notify: Report which specialists needed based on domains

What they handle: Executing tasks in their domain

Validation

Verify the skill executed correctly:

Troubleshooting

Issue: check-task-prerequisites.sh fails

Cause: Missing required artifacts (usually plan.md)

Solution:

•Verify plan.md exists in feature directory
•Run /plan first to generate implementation plan
•Check that feature directory structure is correct

Issue: No test tasks generated

Cause: No contracts or quickstart.md found

Solution:

•Review plan.md for interfaces/APIs that need tests
•Create contract tests for internal module APIs
•Generate at least unit test tasks for core functions
•Update plan if feature truly has no external contracts

Issue: All tasks marked sequential (no [P])

Cause: Tasks all modify same files or unclear file paths

Solution:

•Review task file paths
•Separate concerns into different files
•Test files can always be parallel
•Model files for different entities can be parallel

Issue: Validation shows poor dependency ordering

Cause: Tasks not ordered by dependency hierarchy

Solution:

•Ensure setup tasks first
•Move test tasks before implementation
•Order by: models → services → endpoints → integration
•Put polish tasks last

Issue: Task count very low (<10 tasks)

Cause: Tasks too broad, not granular enough

Solution:

•Break down large tasks into smaller steps
•One task per contract
•One task per entity
•One task per integration point
•Separate testing from implementation

Notes

•Tasks should be immediately executable - specific enough for LLM to complete
•Each task should take ≤4 hours of work (break down if larger)
•Parallel tasks marked [P] can run concurrently (big efficiency gain)
•Test-first means tests MUST come before implementation in task order
•Not all features have all artifact types (adapt based on what's available)
•CLI tools may not have contracts/, simple libraries may not have data-model.md
•Task validation ensures constitutional compliance before execution
•Tasks are the final planning artifact - ready for implementation

Related Skills

•sdd-specification: Step 1 (creates specification)
•sdd-planning: Step 2 (creates implementation plan)
•sdd-tasks: Step 3 (THIS SKILL - creates task list)
•domain-detection: Identifies agents needed for execution
•constitutional-compliance: Validates TDD and contract-first compliance