planning-and-task-breakdown

Planning and Task Breakdown

Decompose work into small, verifiable tasks with explicit acceptance criteria. Good task breakdown is the difference between reliable completion and a tangled mess.

When to Use

• Have a spec and need to break into implementable units
• Task feels too large or vague to start
• Work needs parallelization
• Need to communicate scope

Vertical Slicing

Good (vertical):

Task 1: User can create account (schema + API + UI)
Task 2: User can log in (auth + API + UI)
Task 3: User can view profile (query + API + UI)

Bad (horizontal):

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

Task Template

## Task [N]: [Title]

**Description:** One paragraph on what this accomplishes.

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

**Verification:**
- [ ] Tests pass: [command]
- [ ] Build succeeds: [command]

**Dependencies:** Task numbers or "None"

**Files likely touched:** [list]

**Estimated scope:** S/M/L (1-2 / 3-5 / 5+ files)

Task Sizing

Size	Files	Scope	Example
S	1-2	One component	Add validation rule
M	3-5	One feature slice	User registration
L	5+	Too large — break down	—

Plan Template

# Implementation Plan: [Feature]

## Overview
One paragraph summary.

## 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] | [H/M/L] | [strategy] |

## Open Questions
- [question needing input]

Dependency Graph

Map what depends on what:

Database schema
    │
    ├── API models
    │       │
    │       ├── API endpoints
    │       │       │
    │       │       └── Frontend API client
    │       │
    │       └── Validation logic
    │
    └── Seed data

Build bottom-up: foundations first.

Checkpoints

Add explicit checkpoints between phases:

### Checkpoint: After Tasks 1-3
- [ ] All tests pass
- [ ] Application builds
- [ ] Review with human before proceeding

Parallelization

Safe to Parallelize	Must Be Sequential
Independent slices	Database migrations
Tests for existing code	Shared state changes
Documentation	Dependency chains

Verification Checklist

• Every task has acceptance criteria
• Every task has verification step
• Dependencies identified and ordered
• No task > ~5 files
• Checkpoints exist between phases
• Human reviewed and approved plan

Grok-Specific Guidance

• Always use the todo_write tool (with merge: true for updates) to surface the task list visibly to the user. Use stable IDs like task-1, phase-foundation.
• After breaking down, immediately call todo_write to initialize the list with statuses.
• For large plans, also write a markdown plan file using the template above.