Write a PRD

A PRD aligns product, design and engineering on what to build and why, before the expensive work starts. Engineers use it to find edge cases and push back on scope; testers use it to know what "done" means. It is only as trustworthy as its evidence, so gaps must be visible rather than papered over.

Write a full PRD for: [IDEA] Only if [CONTEXT] is given: Material to work from: [CONTEXT]

1. Problem: who has it, when it happens, what they do today, and the evidence that it matters, using only the material given.
2. Goals and non-goals: the outcomes this release must achieve, and things it deliberately will not do.
3. Success metrics: for each, the metric, its current baseline, the target, and how it will be measured. Include one guardrail metric that must not get worse.
4. Users and use cases: the specific user types and the main scenarios, written as short flows.
5. Requirements: numbered, each one testable, each with a priority (must, should, could). Add non-functional requirements (performance, security, privacy, accessibility, localisation) only where they apply.
6. Edge cases: empty states, errors, permissions and roles, limits, existing users and data, concurrent edits.
7. Risks and dependencies, a rollout plan (flag, beta group, migration of existing data, how to roll back), and open questions with an owner where one is known.

For a one-pager, keep Problem, Goals and non-goals, Success metrics, the must-have requirements and Open questions, in under 500 words.

• Describe what and why, not how. Mention implementation only when it is a real constraint.
• Never invent research, user quotes, numbers, dates or names. Write TODO: … with what is needed, and repeat important gaps under Open questions.
• Mark assumptions with "Assumption:" so reviewers can challenge them.
• Use plain language a new engineer understands. No marketing tone.
• Separate what you verified from what you inferred. Mark inferences as such.
• When you do not know, say "I don't know" once and state what would settle it.

[Feature name]

A status line: Draft · Owner: [TODO unless given] · Last updated: [TODO unless known]. Then the sections in this order, each as ##: Problem, Goals and non-goals, Success metrics (as a table: metric, baseline, target, how measured), Users and use cases, Requirements (as a table: id, requirement, priority), Edge cases, Risks and dependencies, Rollout, Open questions. For a one-pager, include only the sections named in the task.