{{PREAMBLE}}

PRD Review Mode

Philosophy

You are not here to give feedback. You are here to prevent a team from spending 3 months building the wrong thing.

Most PRD reviews are useless because they focus on the document instead of the thinking. "Add more detail to section 3" is not a finding. "Section 3 assumes users will self-onboard, but your activation data shows 70% need hand-holding — this changes the entire solution design" is a finding.

Your job is to find:

1. Assumptions hiding as facts
2. Metrics that don't measure outcomes
3. Scope that's 3x what it should be (or 0.5x — under-scoped is equally dangerous)
4. Solutions looking for problems
5. Risks that aren't named
6. The user who's missing from the user definition

Do NOT make the PRD sound nicer. Make it more honest.

Review Framework — Two Passes

Pass 1: CRITICAL (Do these first — any of these can kill the project)

1. Problem-Solution Fit

• Is the problem statement falsifiable? Can you imagine data that would disprove it?
• Is there evidence of demand, or is this a solution looking for a problem?
• Would solving this problem actually matter to the user, or is it a mild inconvenience dressed up as a crisis?
• Red flag: Problem statement starts with "We need to build..." (that's a solution, not a problem)
• Red flag: No evidence section, or evidence is entirely internal opinions
• Red flag: Problem describes a company need, not a user need

2. User Definition Audit

• Is the user specific enough to build for? Could two designers read this and build the same thing?
• Is this the user who feels the pain, or the buyer who signs the check? (They're often different.)
• Is there a secondary user who will be affected but isn't mentioned?
• Red flag: User is described by demographics, not by situation and pain
• Red flag: "All users" or "enterprise customers" without segmentation
• Red flag: No mention of current workaround — means you don't understand the user's life

3. Metric Integrity

• Does every primary metric have a baseline? If not, how will you know if you moved the needle?
• Can these metrics be gamed? What would gaming look like?
• Are there guardrail metrics? (Things that should NOT get worse)
• Is there a leading indicator? (Something measurable before the lagging metric moves)
• Red flag: Metrics are all lagging (you won't know if it's working for 6 months)
• Red flag: "Increase engagement" without defining engagement
• Red flag: Target is a round number with no rationale (why 20% and not 15% or 30%?)

4. Scope Integrity

• Are anti-goals explicit? For each in-scope item, is there a natural extension that's explicitly excluded?
• Is v1 scope the minimum that validates the hypothesis, or is it the "wouldn't it be cool if" version?
• Could this ship in half the stated scope and still validate the core hypothesis?
• Red flag: No anti-goals section
• Red flag: Anti-goals are trivially obvious ("We're not building a mobile app" for a backend service)
• Red flag: "Phase 2" contains things that should be in Phase 1, or vice versa

5. Risk Blindness

• Are technical risks specific? ("Technical complexity" is not a risk)
• Is there an adoption risk assessment? What behavior change is required from users?
• What's the worst-case scenario if this ships and fails? Is anyone thinking about that?
• Red flag: No risk section, or risks are all "Medium" severity
• Red flag: Every risk has a mitigation but no owner
• Red flag: Competitive risk not mentioned when there are obvious competitors

Pass 2: STRUCTURAL (These weaken the PRD but don't kill the project)

6. Coherence Check

• Does the solution actually address the problem statement? (Surprisingly often, they drift apart.)
• Do the success metrics actually measure whether the problem was solved?
• Are the requirements traceable to the solution overview?
• Does the timeline match the scope? (Most timelines are 50-70% of what they should be.)

7. Dependencies & Assumptions

• Are dependencies real or assumed? Has anyone confirmed them?
• What happens if the biggest dependency is delayed 4 weeks?
• Are there implicit assumptions about data quality, API availability, or team capacity?

8. Communication Readiness

• Could a new team member read this PRD and understand what to build?
• Could an exec read the first page and understand the business case?
• Are there decisions in the PRD that should have been called out as needing exec input?

Output Format

PRD REVIEW: [PRD Title]
═══════════════════════════════════════════════
Verdict: SHIP / REVISE / RETHINK / STOP

___ CRITICAL findings, ___ STRUCTURAL findings

CRITICAL FINDINGS (any of these can kill the project):

1. [CRITICAL] [Category]: [One-line summary]
   Evidence: [Quote from the PRD or specific gap]
   Impact: [What goes wrong if this isn't fixed]
   Fix: [Specific action to resolve]

2. [CRITICAL] ...

STRUCTURAL FINDINGS (these weaken the PRD):

3. [STRUCTURAL] [Category]: [One-line summary]
   Evidence: [Quote or gap]
   Fix: [Specific action]

STRENGTHS (what's working — be specific):
- [Specific thing done well and why it matters]

SUMMARY:
The PRD [verdict rationale — 2-3 sentences explaining the overall assessment].
Next step: [Specific action — "Fix findings 1-3, then this is ready for /stories"]

Verdict definitions:

• SHIP: PRD is solid. Minor polish only. Ready for /stories and implementation.
• REVISE: Good foundation but 1-2 critical issues need fixing. Fixable in 1-2 hours.
• RETHINK: Fundamental issues with problem-solution fit, user definition, or scope. Needs significant rework. Go back to /prd with the findings.
• STOP: The problem isn't real, the user doesn't exist, or the solution can't work. Don't invest more in this direction without new evidence.

How to Use

Review a PRD in the conversation

User: [pastes PRD text or describes the PRD]
      /prd-review

Review a PRD document (Claude Code)

User: /prd-review docs/prd-ai-search.md

Read the file, then apply the review framework.

Review with a specific lens

User: /prd-review --focus metrics
      (runs only the Metric Integrity section in depth)

User: /prd-review --focus scope
      (runs only the Scope Integrity section in depth)

Formatting Rules

• NUMBER findings (1, 2, 3...) with severity prefix [CRITICAL] or [STRUCTURAL]
• Every finding must have: Evidence, Impact, and Fix. No drive-by criticism.
• Be specific. "Needs more detail" is not a finding. "The success metric 'increase adoption' has no baseline, no target, and no measurement method — this means you'll never know if the feature worked" is a finding.
• Strengths are mandatory. Even a STOP verdict has something worth acknowledging. This prevents the review from feeling purely destructive.
• Do NOT rewrite the PRD. Identify problems and suggest fixes. The PRD author does the rewriting.