Product Requirements Document (PRD) Writing

There is a prompt instruction at https://www.zangwei.dev/prompts/product-execution/product-requirements-document-prd-prompt . Extract and follow the prompt to create file /docs/handbook/product/{version|feature}/prd.md

You are a senior Product Manager. Write a PRD (Product Requirements Document) for the product at its current stage.

## Target readers
- Product, operations, engineering, QA, etc.
Purpose: ensure everyone clearly understands:
1) what to build (which features, what is core vs non-core)
2) how it should work (interaction, flows, business logic details)
3) when it should be delivered (milestones and cadence)

## What a PRD is
- An executable contract between product and engineering
- Must describe both what and how (interaction + logic)
- Every requirement must be verifiable, testable, and deliverable

## General requirements
- Strictly follow defined product boundaries (what NOT to build)
- Avoid vision-speak and vague words (support/optimize/improve)
- Provide clear done/acceptance standards for each requirement
- Describe interaction and logic in enough detail for engineering & QA to implement and test
- If info is insufficient to specify "how", list it as risk/open questions

---

## PRD output structure

1) Background & goals
- Roadmap stage and version scope
- What core problem does this version solve?
- Which success criteria/metrics does it map to (North Star/guardrails)?

2) Delivery plan & milestones
- Expected delivery cycle and key milestones (dev done, integration, test, launch)
- Deliverables per milestone
- Release blockers (conditions that must delay/rollback)

3) Product overview (what to build)
- One-sentence: what does this version do?
- Feature list (by module or user task)
- Core vs non-core (explicitly label)
- Explicit exclusions (continue boundaries)

4) Target users & core scenarios
- Who is the primary user?
- In what concrete scenarios do they use it?
- What single core task does this version focus on?
- Brief primary journey from entry to result

5) Scope
- Included scope
- Excluded scope (and why: not MVP / later / not building)
- Boundaries and collaboration scope with other systems/teams

6) Detailed requirements (how it works: interaction & logic)
Describe item by item (module -> feature). Each requirement must include:

6.1 Requirement description (user view)
- What task does the user complete, and what result do they get?

6.2 Interaction flow (as detailed as possible)
- entry/page
- user steps (click/input/select)
- system feedback (loading, messages, success/failure)
- state changes (before/after)
- key copy examples (if it affects understanding/conversion)

6.3 Business rules
- triggers and prerequisites
- role/permission differences (if any)
- data rules (validation, dedupe, priority, defaults)
- constraints/limits (frequency, size, format)

6.4 Edge cases & exceptions
- handling for common exception cases
- failure fallback (default values, retry prompts, safe path)
- explicit non-handled cases for this version (and why)

6.5 Acceptance criteria (testable)
- Given/When/Then or equivalent format
- pass criteria and fail criteria

7) Non-functional requirements
Only include items that directly impact success, e.g.:
- performance floors (latency, throughput, concurrency)
- reliability (availability, error-rate thresholds)
- security & compliance baselines (privacy, permissions, auditing)
- usability requirements (primary path clarity, copy clarity)

8) Dependencies, assumptions, risks
- key dependencies (external APIs, third parties, data readiness, staffing)
- assumptions
- risk list (impact, likelihood, mitigations)
- open questions (anything that blocks specifying "how")

9) QA & acceptance plan
- test scope (functional, regression, compatibility, performance)
- acceptance checklist (must-pass core paths)
- pre-launch gates
- post-launch metrics/alerts to monitor

---

## Output requirements
- Technical approach can be mentioned at a high level, but do not turn this into a technical design doc
- Interaction and logic must be specific enough to implement and test
- Do not add unvalidated new requirements
- Every requirement must be testable/acceptable

End with 3–5 bullet points:
"Is this PRD sufficient for product/engineering/QA/ops to execute with minimal back-and-forth?"