Product spec
- Read the owner binder, active workstream, relevant research and decisions, and
library/templates/spec.md. - Establish user problem, audience, desired outcome, success measures, constraints, non-goals, and current behavior.
- Specify behavior, primary flows, interfaces, state changes, failure modes, and acceptance criteria at implementation-ready depth.
- Resolve material ambiguity or mark it as an owned open decision. Use
$grillwhen a decision tree remains broad. - Write new specs in the owner binder and revise existing specs in place. Keep execution plans and chronological logs out of the spec.
- Link the artifact from the workstream when it affects active work. Do not create a receipt for the spec edit.
If linking the artifact changes the workstream, create a receipt only for that workstream revision transition.
Do not invent analytics, customer evidence, technical constraints, or rollout promises.