Work Breakdown

A plan is right when each task has one outcome you can check with one command, and the order puts the riskiest thing first.

If there is no spec, use spec-writing first. Planning against unwritten requirements produces a plan that changes every day.

Process

1. Read the repository before planning. Existing patterns constrain the plan more than preferences do. Note the conventions you found, with paths, and plan inside them or state the deliberate deviation.
2. Cut along seams that already exist. A task spanning three modules is either three tasks or one badly-drawn boundary. Prefer boundaries the code already has.
3. Order by risk, not by ease. The task that could invalidate the rest of the plan goes first. If an unknown could do that, task one is a spike whose output is an answer, not code you keep.
4. Size to one verifiable outcome. A task is right-sized when its definition of done is a single command whose output you can read. Three commands means three tasks.
5. Assign the lowest tier that clears the ceiling (references/escalation-ladder.md). Over-assignment hides a vague brief.
6. Write a brief per task. A task without one comes back wrong, and that is the planner's defect.
7. State dependencies explicitly. Tasks with no dependency between them can run in parallel, but two tasks that edit the same file are one task.

Task format

- [ ] **<id> · <title>** — `<agent>`
  - Goal: <one sentence in observable behavior>
  - Files in scope: <explicit paths>
  - Pattern to follow: <path:line>
  - Definition of done: `<the single command that must pass>`
  - Out of scope: <what to leave alone>
  - Stop condition: <what triggers an escalation>
  - Depends on: <ids, or none>

Sizing heuristics

Ordering

• Riskiest first. The purpose of order is to find out early that the plan is wrong.
• A task that unblocks several others outranks a task that unblocks none.
• Group tasks that touch the same file so they do not run in parallel.
• Prefer an order where each step leaves the system working. A plan with a broken middle cannot be paused, and plans always get paused.

Output

## Plan: <feature>

### Sequence rationale
<which task removes the most risk, and why this order>

### Parallelisable
<which ids can run at once, and which must not share files>

### Tasks
<the task list>

### Not in this plan
<what was deliberately left out>

Verification

• Every task has a definition of done that is a runnable command.
• Every task is assigned a tier, and the assignment clears that tier's ceiling.
• The dependency graph has no cycle.
• The first task is the riskiest, or the rationale says why not.
• No two parallel tasks edit the same file.

Red flags