Decompose so it survives Plan
Write the specification so it decomposes into four to eight file-scoped tasks, and split it when it does not.
Decomposable spec
A spec that cannot be split produces a change nobody can review
Every criterion maps to work that could be reviewed on its own.
Sibling repository../payments-validation-fixture836a75dShared with course 301. You work from specs/product/payments.md rather than the diff.
Why this stage exists
Course 301 states that an oversized change is a planning problem no validation workflow can fix. The person who can fix it is the one writing the spec.
Four to eight tasks per spec is the target. Work that cannot decompose that far returns to specification rather than to a longer agent run.
What you start from
Work from these inputs only. Anything not on this list is either a later stage’s concern or a decision you do not own.
- Acceptance contract
- Your criteria from stage 3.
- Scope boundary
- What the slice excludes, from stage 4.
- The cadence
- One task is roughly 15 to 30 minutes of agent work and one reviewable diff.
A spec that cannot be split produces a change nobody can review
One worked pass, so the shape of the work is visible before you do it on your own.
- Map each criterion to the work it implies.
- Estimate the files each piece of work would touch.
- Mark any criterion whose work cannot be reviewed on its own.
- Split it, or return the criterion to specification.
What this turns onA criterion that touches everything is usually carrying more than one decision. Splitting the criterion is the fix, not splitting the pull request.
Do the work
- Produce the decomposable spec for the refund slice.
- Find the criterion that will not split and say why.
- Rewrite it as two criteria and check the result.
- Confirm the slice lands between four and eight tasks.
You produce
Decomposable spec
- Criterion
- Work it implies
- Files likely touched
- Reviewable alone
- Split required
Challenge your own result
One criterion touches 20 files. Is that a problem?
Show how this resolves
It depends which 20. A mechanical rename across 20 files is fine. A behavioral change across 20 unrelated modules means the criterion carries more than one decision and needs splitting before anyone writes code.
Ready to continue when
- Every criterion maps to work that could be reviewed on its own.
- The slice lands between four and eight tasks, or the excess returned to specification.
What transfersSize work by what can be reviewed, not by what can be built.
Source · 08 Cadence and decomposition