PRD Delivery Lifecycle
Maintain one versioned delivery model across three connected loops:
- Define and authorize — establish the problem, scope, decisions, contracts, risks, and acceptance evidence.
- Build and prove — implement vertical slices with tests and layer-appropriate validation.
- Accept and prepare release — reconcile feedback, close evidence gaps, and identify remaining authority gates.
Read evidence-contract.md for evidence layers and state-machine.md for feedback and invalidation rules.
Start from authoritative evidence
Before editing:
- identify the requirement owner and authoritative source;
- separate facts, assumptions, policy choices, and unresolved questions;
- enumerate producers, consumers, states, failure paths, and compatibility surfaces;
- define explicit non-goals and authority boundaries;
- state which evidence will prove each acceptance criterion.
Reuse the repository's existing product-spec location. If none exists, create the smallest coherent feature record containing source, review, decisions, implementation plan, verification, and release notes.
Maintain the trace graph
Keep durable identifiers and links for:
REQ -> DEC -> CONTRACT -> TEST -> SLICE -> VERIFY -> RELEASE
Every implementation slice must trace back to a requirement and forward to verification. Every changed decision must identify which downstream nodes are stale.
Execute in vertical slices
For each slice:
- choose one user-observable or contract-observable outcome;
- add or identify the failing test or reproducible evidence;
- implement the smallest coherent change;
- run targeted checks, then broader checks proportional to risk;
- update trace links, evidence, and unresolved risks;
- request acceptance only when the required evidence layer exists.
Do not equate static analysis with runtime behavior, a passing test with deployment, or deployment with user acceptance.
Process feedback
Convert each feedback item into a packet containing the claim, evidence, impacted identifiers, classification, decision owner, and disposition. Invalidate only the affected downstream graph, then rerun the required checks. Never silently rewrite the requirement history.
Completion contract
Report:
- behavior before and after;
- requirement-to-evidence trace status;
- changed components and their responsibilities;
- validation by layer and its limitations;
- unresolved decisions, risks, migrations, rollout, and rollback needs;
- exact authority still required for commit, push, merge, deploy, or release.
1---2name: prd-delivery-lifecycle3description: Drive a product requirement from evidence-backed definition through implementation, verification, acceptance, and release readiness. Use for multi-step feature delivery, PRD authoring, requirement changes, feedback rounds, traceability, or cross-component work where decisions and evidence must remain coherent.4---56# PRD Delivery Lifecycle78Maintain one versioned delivery model across three connected loops:9101. **Define and authorize** — establish the problem, scope, decisions, contracts, risks, and acceptance evidence.112. **Build and prove** — implement vertical slices with tests and layer-appropriate validation.123. **Accept and prepare release** — reconcile feedback, close evidence gaps, and identify remaining authority gates.1314Read [evidence-contract.md](references/evidence-contract.md) for evidence layers and [state-machine.md](references/state-machine.md) for feedback and invalidation rules.1516## Start from authoritative evidence1718Before editing:1920- identify the requirement owner and authoritative source;21- separate facts, assumptions, policy choices, and unresolved questions;22- enumerate producers, consumers, states, failure paths, and compatibility surfaces;23- define explicit non-goals and authority boundaries;24- state which evidence will prove each acceptance criterion.2526Reuse the repository's existing product-spec location. If none exists, create the smallest coherent feature record containing source, review, decisions, implementation plan, verification, and release notes.2728## Maintain the trace graph2930Keep durable identifiers and links for:3132```text33REQ -> DEC -> CONTRACT -> TEST -> SLICE -> VERIFY -> RELEASE34```3536Every implementation slice must trace back to a requirement and forward to verification. Every changed decision must identify which downstream nodes are stale.3738## Execute in vertical slices3940For each slice:41421. choose one user-observable or contract-observable outcome;432. add or identify the failing test or reproducible evidence;443. implement the smallest coherent change;454. run targeted checks, then broader checks proportional to risk;465. update trace links, evidence, and unresolved risks;476. request acceptance only when the required evidence layer exists.4849Do not equate static analysis with runtime behavior, a passing test with deployment, or deployment with user acceptance.5051## Process feedback5253Convert each feedback item into a packet containing the claim, evidence, impacted identifiers, classification, decision owner, and disposition. Invalidate only the affected downstream graph, then rerun the required checks. Never silently rewrite the requirement history.5455## Completion contract5657Report:5859- behavior before and after;60- requirement-to-evidence trace status;61- changed components and their responsibilities;62- validation by layer and its limitations;63- unresolved decisions, risks, migrations, rollout, and rollback needs;64- exact authority still required for commit, push, merge, deploy, or release.
levyflux