Task breakdown

Task breakdown

A useful task breakdown is the difference between work that ships reliably and work that sprawls into a tangled mess. This skill produces tasks that an individual can pick up, finish, and verify in one session — organized so the project reaches a working state at every checkpoint, not only at the end.

Non-goals

• Not a planning doc. For a multi-phase project plan with timelines and owners, use /role-pgm:project-planner.
• Not a sprint plan. For iteration-scoped scrum/Shape Up planning, use /role-pgm:sprint-planner.
• Not a spec. If the input is fuzzy, stop and send the user to /role-pm:spec-draft or /role-ceo:office-hours.

Principles

• Slice vertically. Each task moves one complete feature path forward — DB + API + UI + test all together — not "all DB first, then all API." Horizontal slicing means the project never works until the end, and you can't verify anything mid-flight.
• Size for one session. Each task fits in 2-4 hours of focused work. Bigger tasks hide risk and complexity.
• Satisfiable dependencies. Every task either has no dependencies or depends only on tasks that come before it in the order.
• Verification every 2-3 tasks. After a small batch, there's a checkpoint: does the thing still work? Tests pass? Manual check? If not, stop and fix before moving on.
• Foundations first. Shared primitives, types, configuration — the stuff everything else leans on — get built before the features that lean on them.

Workflow

1. Read the input

Read the spec / plan / requirement end to end. Identify:

• The user-facing outcome (what gets better once done)
• The components touched (DB? API? UI? external services? docs?)
• Explicit constraints (deadlines, style guides, tech to avoid)
• What's already in the codebase that can be reused — check for existing utilities and patterns before proposing net-new work

If any of these are unclear, stop and ask one specific question at a time. Don't guess structure on a fuzzy spec.

2. Map the dependency graph

Identify the minimal set of components each feature path depends on. Sketch the graph mentally (or write it out briefly in the output).

Mark each node as:

• Foundation — types, shared utilities, config, migrations, base components
• Feature slice — one complete user-facing path
• Polish — docs, analytics, a11y passes, perf tweaks, error messages

Foundations come first. Feature slices are ordered by dependency and by learning value — start with the slice that most quickly reveals whether the approach works.

3. Write the tasks

Each task has:

### Task N: <verb + object>
**What:** <1 sentence>
**Why:** <1 sentence — how this moves the outcome forward>
**Acceptance criteria:**
- <specific, observable>
- <specific, observable>
**Files touched (estimate):** <count + most-likely paths>
**Depends on:** <task numbers, or "none">
**Verification:** <how you'll know this task is done — test passes, manual check, screenshot, etc.>

Rules:

• Acceptance criteria are observable. "Handles errors gracefully" is not. "Returns 400 with error code invalid_input when payload fails validation, and log entry includes request ID" is.
• Files touched is an estimate. If it's more than 5, the task is probably too big — consider splitting.
• Verification is the escape valve. If you can't describe how to verify a task is done, the acceptance criteria aren't sharp enough.

4. Order and checkpoint

Order the tasks so that:

• Foundations precede anything that uses them
• Each feature slice is contiguous (one slice completes before the next starts, unless they're truly independent)
• Every 2-3 tasks, insert a checkpoint: a named moment where the project is verified working before moving on

Checkpoint example:

### Checkpoint after Task 4
- All existing tests pass
- New endpoint `/v1/widgets` returns 200 on happy path
- Manual verification: create a widget via curl, see it in the DB

5. Output

# Task breakdown: <input title>

**Vertical slices in order:**
1. <slice name> — tasks 1-4 — checkpoint after 4
2. <slice name> — tasks 5-7 — checkpoint after 7
3. <slice name> — tasks 8-10 — final checkpoint

---

## Foundations
### Task 1: <...>
<full task spec>

### Task 2: <...>
...

## Slice 1: <slice name>
### Task 3: <...>
...

### Checkpoint after Task N
- <verification step>

## Slice 2: <slice name>
...

## Polish
### Task K: <...>
...

---

## Total estimate
- <N tasks>, roughly <hours> of focused work
- Assumes <any assumption made, e.g. "existing auth middleware reused without modification">
- Risks / unknowns: <things that could invalidate the breakdown>

Don't

• Don't write tasks with acceptance criteria that boil down to "it works."
• Don't group all DB work into one task "because it's all the same area." That's horizontal slicing. The project won't work until everything lands.
• Don't skip foundations to get to "the interesting work" faster. Foundation debt compounds worse than interest on a credit card.
• Don't write tasks larger than 4 hours. If one emerges, break it and re-order.
• Don't produce a breakdown without checkpoints. Without them, you find out at task 15 that task 3 was wrong.

---

Methodology inspired by the Addy Osmani "planning-and-task-breakdown" skill.