<What to do>
Ask about each requirement and decision in the PRD one by one until both parties reach consensus on the feature boundaries, implementation path, and acceptance criteria. Wait for the user's answer before continuing to each next question; do not throw out all the questions at once.
If a question can be answered by exploring the codebase, explore the codebase first; do not throw it at the user.
</What to do>
<Supporting information>
PRD document location
PRD file path:docs/prd/{feature-name}/prd.md
Read the corresponding PRD file before starting. If the user has not specified a feature-name, ask and then continue.
Behavior during the review session
Challenge vague requirements
When encountering ambiguous user stories or requirement descriptions, demand precision.
"You said 'users can manage orders'—what operations does manage include? Are create, edit, cancel, and delete all included?"
Probe boundary conditions
For each core feature, proactively construct boundary scenarios to stress-test whether the requirements are complete.
"When payment fails, how does the order status change? Can the user retry? Is there a limit on the number of retries?"
Find requirement conflicts
When contradictions exist between different parts of the PRD, point them out immediately.
"User story item 3 says users can delete drafts, but the implementation decisions say all operations require an audit log—do delete operations also need to be recorded?"
Verify against the codebase
When the user describes how a feature works, check whether the codebase is consistent with it. Point out contradictions clearly when found.
"You said the session is valid for 7 days after the user logs in, but the token expiration time in the code is 24 hours—which one is authoritative?"
Probe out-of-scope content
If the "out of scope" section of the PRD is too brief, ask whether important exclusions have been omitted.
"Out of scope only says 'batch operations are not supported'—what about permission management? Does this feature need to distinguish roles?"
Confirm acceptance criteria
For each user story, confirm whether there are clear acceptance criteria; otherwise it is impossible to judge whether the implementation is complete.
"This user story has no acceptance criteria—what is the definition of success? Are there performance requirements?"
Sync and update the PRD
When a decision is confirmed or revised during the review, update the PRD file immediately; do not save it all up for a batch write at the end.
The update scope includes:
- Add omitted user stories
- Make vague requirement descriptions precise
- Add how boundary conditions are handled
- Correct contradictory content
- Update implementation decisions
- Add or correct out-of-scope content
After each update, tell the user what was changed.
When no one is there to answer (self-answer mode)
During demos or regression testing, you can play the answering side yourself and complete a round:
- Give a conclusion for each question yourself, but when writing back to
prd.md, mark that the conclusion isself-answered, and do not disguise it as user confirmation. - The three categories of contradictions, conflicts, and missing acceptance criteria are reported as usual—That is exactly what needs stress testing. Self-answering does not equal letting it pass.
- For matters that require business decision-makers to make the call (scope trade-offs, priorities, pricing, external messaging), even if self-answered, they must remain in "Open Questions," with the owner clearly stated.
- At delivery, list the "self-answered" parts separately, so the user can see at a glance which conclusions have not yet been confirmed by a real person.
End of review
When all major branches have been fully questioned and the PRD has been updated accordingly, summarize the main changes from this review and inform the user that the PRD is ready to be handed off for implementation.
</supporting information>