Plan product outcomes
Read product, artifacts, memory, and safety.
Route
- Use
prd when the problem, users, goals, scope, or requirements are not yet an approved product contract.
- Use
roadmap only when .planning/flow/product/prd.md exists and its gate is approved.
PRD procedure
- Inspect existing product and repository context before interviewing.
- Ask one product decision at a time: problem, users, outcomes, non-goals, journeys, rules, requirements, risks, and release evidence.
- Label facts, user decisions, assumptions, dependencies, and open questions distinctly.
- Write the complete PRD using product.
- Trace each requirement with a stable ID.
- Present the PRD for explicit approval and stop. Do not generate a roadmap from an unapproved PRD.
Roadmap procedure
- Read the approved PRD and applicable project context.
- Build
Phase → Epic → Feature → Task from outcomes rather than technical layers.
- Give every node a parent, PRD requirement links, objective, acceptance outcome, dependencies, risks, estimate range, and status.
- Validate there are no orphan requirements or tasks and every phase delivers measurable value.
- Persist the hierarchy under
.planning/flow/product/roadmap/ and present it for approval.
Work inline by default. A roadmap worker is allowed only when the user explicitly requests parallel agent work; the primary conversation owns approval.
Output
Return mode, artifact paths, traceability coverage, unresolved decisions, gate result, and next valid action.
1---2name: flow-product3description: Creates an approval-gated product requirements document or decomposes an approved PRD into a traceable roadmap, covering product-level problems, new initiatives, multi-feature scope, PRDs, release outcomes, and roadmap planning.4---56# Plan product outcomes78Read [product](../../references/product.md), [artifacts](../../references/artifacts.md), [memory](../../references/memory.md), and [safety](../../references/safety.md).910## Route1112- Use `prd` when the problem, users, goals, scope, or requirements are not yet an approved product contract.13- Use `roadmap` only when `.planning/flow/product/prd.md` exists and its gate is approved.1415## PRD procedure16171. Inspect existing product and repository context before interviewing.182. Ask one product decision at a time: problem, users, outcomes, non-goals, journeys, rules, requirements, risks, and release evidence.193. Label facts, user decisions, assumptions, dependencies, and open questions distinctly.204. Write the complete PRD using [product](../../references/product.md).215. Trace each requirement with a stable ID.226. Present the PRD for explicit approval and stop. Do not generate a roadmap from an unapproved PRD.2324## Roadmap procedure25261. Read the approved PRD and applicable project context.272. Build `Phase → Epic → Feature → Task` from outcomes rather than technical layers.283. Give every node a parent, PRD requirement links, objective, acceptance outcome, dependencies, risks, estimate range, and status.294. Validate there are no orphan requirements or tasks and every phase delivers measurable value.305. Persist the hierarchy under `.planning/flow/product/roadmap/` and present it for approval.3132Work inline by default. A roadmap worker is allowed only when the user explicitly requests parallel agent work; the primary conversation owns approval.3334## Output3536Return mode, artifact paths, traceability coverage, unresolved decisions, gate result, and next valid action.
pwdev-solucoes