khuynh22 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
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.
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.
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.
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.
Assign the lowest tier that clears the ceiling (
references/escalation-ladder.md). Over-assignment hides a vague brief.Write a brief per task. A task without one comes back wrong, and that is the planner's defect.
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
| Symptom | Fix |
|---|---|
| The definition of done needs three commands | Split into three tasks |
| The task title contains "and" | Split at the "and" |
| You cannot name the files in scope | You do not understand it yet. Investigate first, as its own task. |
| The task touches more than one module | Either split, or the boundary is wrong |
| Estimating it feels impossible | It contains an unknown. Make removing that unknown task one. |
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
| Thought | Reality |
|---|---|
| "I'll do the easy tasks first for momentum" | You will discover the plan is wrong at the end instead of the start. |
| "This task is obvious, no brief needed" | Obvious to you. The brief is for whoever picks it up. |
| "I'll assign it senior to be safe" | Over-assignment is a symptom of a vague brief, not caution. |
| "The order does not matter much" | Order is the plan. If it did not matter you would not need one. |
| "I'll write this task myself, it is small" | Then it is a T0 task with a brief. Your output is the plan. |
| "We can plan the rest as we go" | Plan to the next verifiable milestone at least. Beyond that, say so explicitly. |