home / skills / athola / claude-night-market / task-planning

This skill generates phased, dependency-ordered task plans from specifications, identifying parallelizable work and guiding implementation.

npx playbooks add skill athola/claude-night-market --skill task-planning

Review the files below or copy the command above to add this skill to your agents.

Files (4)
SKILL.md
3.8 KB
---
name: task-planning
description: 'Generate phased, dependency-ordered tasks from specs. Identifies parallelization
  opportunities.


  task planning, dependency ordering, phased breakdown, parallel tasks

  Use when: converting specifications to implementation tasks

  DO NOT use when: writing specs - use spec-writing. Not for execution - use speckit-implement.'
category: planning
tags:
- speckit
- tasks
- planning
- implementation
- dependencies
dependencies:
- superpowers:writing-plans
- superpowers:executing-plans
tools: []
modules:
- phase-structure.md
- dependency-patterns.md
- tech-stack-patterns
progressive_loading: true
usage_patterns:
- task-generation
- dependency-ordering
- implementation-planning
complexity: intermediate
estimated_tokens: 1200
---

# Task Planning

## Overview

Transforms specifications and implementation plans into actionable, 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

```markdown
## 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
## Troubleshooting

### Common Issues

**Command not found**
Ensure all dependencies are installed and in PATH

**Permission errors**
Check file permissions and run with appropriate privileges

**Unexpected behavior**
Enable verbose logging with `--verbose` flag

Overview

This skill converts specifications and implementation plans into phased, dependency-ordered tasks with clear verification criteria. It produces a five-phase breakdown from setup through polish and highlights safe parallelization opportunities. Tasks include IDs, dependencies, affected files, and completion criteria to support predictable implementation.

How this skill works

Given a spec, the skill identifies discrete work items, assigns each to one of five phases (Setup, Foundation, Core Implementation, Integration, Polish), and orders tasks by dependencies. It enforces file-coordination rules and nonconflicting criteria before marking tasks as parallelizable. Outputs are ready-to-run task lists suitable for sprint planning or ticket creation.

When to use it

  • Converting a specification into an implementation-ready task list
  • Planning feature rollout with explicit phase ordering
  • Identifying which tasks can be executed in parallel to speed delivery
  • Breaking complex features into testable, verifiable increments
  • Preparing input for ticketing systems or sprint planning

Best practices

  • Map every requirement to at least one task and include clear completion criteria
  • Keep tasks right-sized: avoid overly large or tiny tasks
  • Mark [P] only after verifying no file overlap, no shared global state, and all prerequisites met
  • Use the five-phase structure to sequence infra, core work, integration, then polish
  • Explicitly list file paths to prevent hidden merge conflicts

Example use cases

  • Turn a new authentication feature spec into phased tasks with tests and API contracts
  • Plan a migration by scheduling setup, data-model changes, core migration logic, integration checks, and final validation
  • Split a monolithic feature into concurrent front-end and back-end tasks that meet parallel criteria
  • Create a sprint backlog from product requirements with dependency links and verification steps

FAQ

How do you decide phase assignment for a task?

Assign tasks based on their role: setup/config goes to Phase 0, data models and tests to Phase 1, business logic to Phase 2, external integrations to Phase 3, and optimizations/docs/tests to Phase 4.

When is a task safe to mark as parallel [P]?

Only when there is no file overlap, no shared configuration or global state, all dependencies are satisfied, code paths won't conflict, and outputs are independent.