Planning and Task Breakdown

Decompose work into small, verifiable tasks with explicit acceptance criteria.

When to Use

• You have a spec and need to break it into implementable units
• A task feels too large or vague to start
• Work needs to be parallelized across multiple agents or sessions
• You need to communicate scope to a human
• The implementation order isn't obvious

The Planning Process

Step 1: Enter Plan Mode

Before writing any code, operate in read-only mode:

• Read the spec and relevant codebase sections
• Identify existing patterns and conventions
• Map dependencies between components
• Note risks and unknowns

Do NOT write code during planning.

Step 2: Identify the Dependency Graph

Map what depends on what:

Database schema
    │
    ├── API models/types
    │       │
    │       ├── API endpoints
    │       │       │
    │       │       └── Frontend API client
    │       │               │
    │       │               └── UI components
    │       │
    │       └── Validation logic
    │
    └── Seed data / migrations

Step 3: Slice Vertically

Build one complete feature path at a time:

Bad (horizontal slicing):

Task 1: Build entire database schema
Task 2: Build all API endpoints
Task 3: Build all UI components
Task 4: Connect everything

Good (vertical slicing):

Task 1: User can create an account (schema + API + UI)
Task 2: User can log in (auth schema + API + UI)
Task 3: User can create a task (task schema + API + UI)
Task 4: User can view task list (query + API + UI)

Step 4: Write Tasks

Each task follows this structure:

## Task [N]: [Short descriptive title]

**Description:** One paragraph explaining what this task accomplishes.

**Acceptance criteria:**
- [ ] [Specific, testable condition]
- [ ] [Specific, testable condition]

**Verification:**
- [ ] Tests pass: `npm test -- --grep "feature-name"`
- [ ] Build succeeds: `npm run build`
- [ ] Manual check: [description of what to verify]

**Dependencies:** [Task numbers this depends on, or "None"]

**Files likely touched:**
- `src/path/to/file.ts`
- `tests/path/to/test.ts`

**Estimated scope:** [Small: 1-2 files | Medium: 3-5 files | Large: 5+ files]

Step 5: Order and Checkpoint

Arrange tasks so that:

1. Dependencies are satisfied
2. Each task leaves the system in a working state
3. Verification checkpoints occur after every 2-3 tasks
4. High-risk tasks are early (fail fast)

Task Sizing Guidelines

| Size | Files | Scope | Example | |------|-------|-------|---------| | XS | 1 | Single function or config change | Add a validation rule | | S | 1-2 | One component or endpoint | Add a new API endpoint | | M | 3-5 | One feature slice | User registration flow | | L | 5-8 | Multi-component feature | Search with filtering | | XL | 8+ | Too large — break it down | — |

Plan Document Template

# Implementation Plan: [Feature/Project Name]

## Overview
[One paragraph summary of what we're building]

## Architecture Decisions
- [Key decision 1 and rationale]
- [Key decision 2 and rationale]

## Task List

### Phase 1: Foundation
- [ ] Task 1: ...
- [ ] Task 2: ...

### Checkpoint: Foundation
- [ ] Tests pass, builds clean

### Phase 2: Core Features
- [ ] Task 3: ...
- [ ] Task 4: ...

### Checkpoint: Core Features
- [ ] End-to-end flow works

## Risks and Mitigations
| Risk | Impact | Mitigation |
|------|--------|------------|
| [Risk] | [High/Med/Low] | [Strategy] |

Parallelization Opportunities

• Safe to parallelize: Independent feature slices, tests, documentation
• Must be sequential: Database migrations, shared state changes
• Needs coordination: Features that share an API contract

Verification

Before starting implementation:

• [ ] Every task has acceptance criteria
• [ ] Every task has a verification step
• [ ] Task dependencies are identified and ordered correctly
• [ ] No task touches more than ~5 files
• [ ] Checkpoints exist between major phases
• [ ] The human has reviewed and approved the plan