Best for
- Changes big enough to lose track of mid-way
- Handing work between sessions, people or AI models
- Making review possible before code exists
What you give it
- The approved change request and the impact findings, if any
What you get back
- A specification: impacted elements, tasks with statuses, done criteria
- A 'resume here' section a fresh session can continue from
- One file, linked one-to-one with its change request
How it works
- Reads the change request and any impact analysis.
- Lists every impacted element: screens, modules, data, tests, docs.
- Breaks the change into tasks with individual done-criteria.
- Pins open questions at the top so nobody builds past them.
- Maintains the statuses and resume-point as work proceeds.
Example
You: Spec the loyalty-points change from its request and impact notes.
Result: A spec listing the six impacted modules and two tables, four tasks with done-criteria, the open pricing question pinned at the top, and resume-here pointing at task one.
Limits — please read
- A spec is only as complete as the impact work behind it.
- It specifies; building and verifying remain their own steps.
- Changing scope mid-build means updating the spec first, not after.