Reviewing a Product Requirements Document

Evaluate a PRD for quality — not agreement with a preferred solution. Focus on whether it's complete, clear, and actionable.

Quick Reference

• Input: A PRD (from create-prd or existing document).
• Output: Findings as Critical, Suggestion, or Note.
• Checks: Completeness, testability, ambiguity, feasibility, edge cases, dependencies.
• Rule: Every finding cites the specific PRD section as evidence; redact sensitive data rather than reproducing it verbatim.

HARD-GATE

DO NOT review the idea — review the document's quality.
DO NOT suggest alternative solutions unless a requirement is infeasible.
EVERY finding MUST cite the specific PRD section, line, or requirement — if the cited text contains sensitive data (API keys, tokens, passwords, credentials), abstract or redact it rather than reproducing it verbatim.

Core Process

1. Receive the PRD — from create-prd, user document, or /tasks/prd-*.md.
2. Scan the checklist (see Review Checklist below) — covers completeness, testability, clarity, feasibility, scope, dependencies, and edge cases.
3. Classify: Critical (blocks implementation), Suggestion (improves it), Note (observation).
4. Produce — findings table with severity, evidence, and recommendation.
5. Verdict: Approved / Approved with Suggestions / Needs Revision.
6. Feedback loop: If verdict is Needs Revision, instruct the author to address Critical findings and resubmit. Re-run this review on the updated PRD before proceeding downstream.

Review Checklist

Apply all applicable items. Skip items that are genuinely not relevant to the PRD's domain.

Completeness

• Goals and success metrics are stated and measurable.
• All in-scope features are listed; out-of-scope is explicit.
• Actors / user roles are identified.
• Non-functional requirements (performance, security, accessibility) are present.

Testability

• Each requirement can be verified with a concrete pass/fail test.
• Acceptance criteria are specific (no vague words like "fast", "easy", "good").
• Edge cases and error states are addressed.

Clarity

• No undefined acronyms or jargon without a glossary entry.
• No ambiguous modal verbs ("should" vs. "must" vs. "may").
• Contradictions between sections are absent.

Feasibility

• Timeline and milestones are realistic given stated scope.
• Dependencies (systems, teams, data) are identified.
• Technical constraints or assumptions are explicit.

Scope & Edge Cases

• Rollback / failure scenarios are described.
• Data migration or compatibility concerns are addressed if applicable.
• Regulatory or compliance requirements are noted if applicable.

Output Style

1. Verdict — Approved / Approved with Suggestions / Needs Revision.
2. Findings table — | # | Severity | Section | Finding | Evidence | Recommendation |
3. Summary — count by severity + one-paragraph assessment.
4. What's Good — acknowledge well-written sections.
5. English only unless user requests otherwise.

Example Findings Table

Integration