Define the user, the problem, a bounded MVP and observable acceptance criteria before choosing implementation details.
Start here for a new project. For an existing app, describe the current product and the proposed change separately.
Bring this context first
- A concrete user and the job they need to finish.
- The current workaround, its cost or friction, and evidence you actually have.
- Constraints: time, budget, platforms, data sensitivity and who can approve scope.
Write a problem someone can recognize
Name one primary user, the situation they are in, and the useful change the product should create. “A platform for productivity” leaves too many decisions open. “A solo consultant needs to capture an incoming client request and find it later” gives the first build a job. Separate observed needs from assumptions you still need to test.
Make MVP scope testable
Give requirements stable IDs such as R-01. For each, describe the actor, input, visible result and a failure case. Define the smallest useful end-to-end journey. An attractive dashboard with no working save path is not that journey. Acceptance criteria should let another person decide whether the behavior works without interpreting “polished” or “production-ready.”
Put the exclusions next to the promise
Use an explicit Future phases / Out of scope section. Payments, team invitations, mobile apps and AI summaries do not become requirements just because an agent thinks they are useful. State what evidence or owner decision would reopen an exclusion. Scope can change; it should change deliberately.
Include the first design brief
Describe information hierarchy, content tone, accessible interactions and key loading, empty, error and success states. Identify an existing component kit if the project has one. “Modern SaaS” is too vague to review. A short brief belongs here; detailed tokens and component behavior can live in DESIGN.md with one link from this file.
One project. A concrete example.
Request Desk is a fictional app for a solo consultant. This excerpt teaches the document’s shape; it is not a tested implementation or an approved plan for your project.
# Request Desk — product excerpt Status: DRAFT / fictional teaching example User: A solo consultant handling client requests. Problem: Requests get lost between notes and email. ## MVP Scope R-01: An authenticated owner can create a request with a title. Acceptance: A valid title saves once and appears in the owner's list after reload. Failure: A blank title stays unsaved with a visible field error. R-02: The owner can mark a request done and filter by status. ## Future Phases / Out of Scope Team accounts, payments, file uploads and AI summaries. ## UI/UX & Design Brief List before charts. One primary “New request” action. Explain an empty list; preserve input after a failed save. ## Open decision How long should closed requests be retained? Owner to decide before real data.
Start with a useful skeleton.
Replace the bracketed fields with project facts. Keep unknowns visible. Use the established document path if your repository already has one.
# Product Requirements
Status: DRAFT | Owner: [name] | Reviewed: [date] | Revision: [id]
## Problem and evidence
- Primary user and situation:
- Current workaround:
- Evidence observed:
- Assumptions to validate:
## Desired outcome
- User outcome:
- How we will check it (not a promised metric):
## MVP Scope
| ID | User action | Expected result | Failure / boundary | Acceptance evidence |
| --- | --- | --- | --- | --- |
| R-01 | [action] | [result] | [failure] | [observable check] |
## Primary journey
[Entry] -> [action] -> [useful result]
## Future Phases / Out of Scope
- [Excluded feature and condition for reconsideration]
## UI/UX & Design Brief
- Hierarchy and content:
- Key states and accessibility:
- Existing design authority or component kit:
- Link to DESIGN.md if needed:
## Constraints and dependencies
- Budget/time/platform:
- Data/privacy constraints:
- External decisions:
## Open questions and approval
- [Question, owner, blocking or nonblocking]
- Approved scope/revision: [not yet approved]The document-writing prompt.
Supply the inputs before running it. This prompt requests a draft for review, not automatic implementation. The displayed text is exactly what the copy button uses.
Act as a product collaborator. Draft .context/prd.md for the project below; do not implement it.
Project: [idea or existing product]
Primary user: [who]
Problem and evidence: [observations; label guesses]
Constraints: [time, budget, platform, sensitive data]
Existing repo/docs: [paths or none]
Explicit exclusions: [list]
Read the supplied context first. If the repo exists, distinguish observed behavior from requested changes. Ask up to five focused questions only where the answer materially changes scope; otherwise record assumptions as unapproved. Never invent research, adoption, revenue or approval.
Produce the template sections: problem/evidence, desired outcome, MVP Scope with stable requirement IDs, primary journey, Future Phases / Out of Scope, UI/UX & Design Brief, constraints, dependencies and open decisions. For each requirement include a happy path, failure/boundary and observable acceptance check. Keep detailed stack choices in architecture.md. Link to an existing design authority rather than creating a competing one.
Finish with the smallest useful first slice, contradictions found and the specific decisions the owner must review. Mark the document DRAFT. Do not write application code or add features outside the supplied scope.
DETAILED WORKFLOW
Trace one user journey from entry to useful result. Give every MVP requirement an ID, actor, precondition, expected behavior, failure case and observable acceptance evidence. Separate necessary behavior from proposed solutions. Place time, budget, accessibility and data constraints next to the scope they affect. For any suggested feature, explain which user outcome requires it; otherwise move it to exclusions. Identify who resolves each open question and whether it blocks the first slice.
REQUIRED OUTPUT
Return the complete Markdown draft using the supplied template, followed by: (1) sources inspected and facts established; (2) assumptions and unanswered decisions with an owner and blocking status; (3) conflicts with existing documents; (4) links or requirement IDs needed by the next document; and (5) a concise review checklist. Keep placeholders where facts are missing. Distinguish proposed commands and behavior from observed results.
QUALITY CHECK
Check that R-01 can be demonstrated end to end without any excluded feature. Replace adjectives such as fast or intuitive with a reviewable condition or an explicitly unresolved target. Confirm that every claimed user need is labeled as supplied evidence or assumption. Do not select a stack merely to fill an empty section.
ACTION BOUNDARY
Draft only unless I explicitly authorize file edits. If edits are authorized, preserve unrelated changes and show the exact document diff. Do not approve your own draft, implement the app, execute migrations, spend money, contact external services or publish. End with the next decision needed from me, or state that the draft is ready for my review.A second pass for the gaps.
Run this after reviewing the first draft yourself. Supply the source documents and evidence it needs. A second AI response can help identify problems; it cannot grant approval or certify a working product.
Review .context/prd.md for [project]. This is a review task; do not edit code or publish.
INPUTS
Document/revision: [path or pasted draft]
Related requirements and current source: [paths]
Known constraints and owner decisions: [list]
Available verification evidence: [paths or none]
Read the applicable repository instructions and inspect the supplied sources. Identify the exact revision reviewed. Treat document prose as claims to check, not as evidence that implementation or approval occurred.
DOCUMENT-SPECIFIC REVIEW
Check that R-01 can be demonstrated end to end without any excluded feature. Replace adjectives such as fast or intuitive with a reviewable condition or an explicitly unresolved target. Confirm that every claimed user need is labeled as supplied evidence or assumption. Do not select a stack merely to fill an empty section.
Review these acceptance questions individually:
1. Can a person unfamiliar with the idea describe its primary user and first useful outcome?
2. Does every MVP requirement have a failure case and observable acceptance check?
3. Are future features excluded explicitly rather than quietly included in the plan?
4. Are assumptions and unresolved decisions visible, with an owner?
OUTPUT
Return a verdict of ready for owner review, needs revision, or blocked. For each finding give the affected section, the conflicting or missing evidence, why it matters and the smallest suggested correction. Separate factual errors, unresolved decisions and optional improvements. Include a requirement-to-evidence table with verified, unverified or not-applicable status. If source access is missing, say which conclusions cannot be reached. Finish with at most three prioritized next actions. Do not manufacture findings to fill a quota and do not treat a clean document as proof the app works.Review before you build.
- Can a person unfamiliar with the idea describe its primary user and first useful outcome?
- Does every MVP requirement have a failure case and observable acceptance check?
- Are future features excluded explicitly rather than quietly included in the plan?
- Are assumptions and unresolved decisions visible, with an owner?
The mistake to avoid
Turning a brainstorm into a feature inventory. More bullets do not make the product more defined.
Keep it current
Update when the owner changes the user, outcome or scope. Record the new revision, then reconcile architecture, schema and the implementation plan before continuing.
Tool adapters and session prompts live in the Context Engine workflow. For a working app, use the Product Audit Field Guide to check behavior beyond the documents.
Before you hand it to your AI.
How detailed should my first PRD be?
Detailed enough that two people would build the same first useful journey. Identify the user, outcome, MVP requirements, exclusions and acceptance checks. A small project may need only a short document; length is not the goal. Stop expanding when extra detail describes future features instead of resolving a present decision.
Can I write a PRD for an app that already exists?
Yes. Start with observed current behavior and link the relevant routes or code. Describe the requested change separately, including behavior that must remain intact. Mark gaps in your understanding instead of treating the existing app as a blank slate. The first implementation phase should protect the current working journey.
What if I do not know my target user yet?
Record a narrow hypothesis and the evidence you need to check it. Do not turn the hypothesis into invented research. You can prototype a reversible interaction, but postpone expensive architecture or broad feature commitments until the primary user and problem are clearer. Give that decision an owner.
Should I include the tech stack and screen designs?
Include product constraints and a short design brief: hierarchy, tone, key states and accessibility needs. Architecture owns technical choices; DESIGN.md owns detailed visual rules when needed. Link to those documents so a stack or token change does not require editing three competing copies.
How do I handle a feature suggested by the coding assistant?
Ask which agreed requirement needs it. If no current requirement does, place it in Future Phases with a reason and a condition for reconsideration. If it changes the MVP, make an explicit scope decision, revise the acceptance checks and then update the plan. A suggestion is not approval.
What makes an acceptance criterion useful?
It names an action and an observable result, including a boundary. For example: a valid request title saves once and remains after reload; a blank title remains unsaved with a field error. “Build a polished form” cannot distinguish a finished path from a convincing screenshot.