Parse PRD

• Assumptions (what you guessed)
• Open Questions (what needs confirmation)

3) Define product shape

Produce crisp decisions, not “maybe”:

• Personas / user segments
• JTBD (job-to-be-done) + pain points
• Out of scope / non-goals
• Success metrics

4) Map the customer journey

Create an end-to-end journey for the primary persona:

• Stages: Discover → Onboard → Core use → Ongoing → Support/Recovery
• User goals, actions, system responses, and failure states per stage

Use references/journey-template.md.

5) Write requirements (with acceptance criteria)

Use a layered structure:

• Epics → User stories → Functional requirements
• Acceptance criteria in plain language (Given/When/Then optional)

Also include:

• Non-functional requirements (performance, security, privacy, accessibility, reliability)
• Data/records the product must manage (entities + key fields), without choosing storage
• Edge cases and error handling
• Roles & permissions

6) Deliver PRD in a standard template

Use the template in references/prd-template.md. Keep it skimmable.

Output requirements

• Default output: one Markdown PRD.
• No tech stack.
• Prefer numbered sections and bullet lists.
• Include: customer journey + requirements + acceptance criteria.

Quality checklist (run before finalizing)

• Every “must” requirement is testable.
• Requirements match the customer journey steps.
• Errors and edge cases are explicit.
• Non-goals prevent scope creep.
• Metrics are measurable.

If the user provides only an idea (examples)

When the user prompt is like:

• “Build a snake game with special controls”
• “Build a financial tracking app with charts”
• “Build a docker container monitor”
• “Build a unified social notifications dashboard”

Do NOT jump to implementation. Convert it into:

• target users + scenarios
• journey map
• functional requirements by epic
• acceptance criteria + edge cases
• measurable success metrics