---
name: planning-and-task-breakdown
description: Break work into small, verifiable vertical slices with acceptance criteria and verification steps. Use when you have a spec or large task that needs decomposition. Trigger phrases: "break down", "create plan", "task breakdown", "implementation plan", "plan the work".
when-to-use: After a spec exists or for any task that feels large/vague; always prefer vertical slices.
---

# 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

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

```markdown
# 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:
```markdown
### 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.