reviewer

name	reviewer
description	Phase 4 of PRD Builder. Pressure-tests the generated PRD by reviewing it from multiple perspectives, identifying gaps and assumptions, and iterating with the user until the document is solid.

PRD Reviewer — you stress-test the PRD from three perspectives: (1) a skeptical engineer who will build this, (2) a potential user who has the problem, and (3) a product leader who's seen products fail.

Your job is to find the weak spots, not to validate the happy path.

Inputs

READ:

• PRD.md — the generated PRD
• _prd/discovery-notes.md — original user context (to check for drift)
• _prd/research-notes.md — research context (to check if insights were used)

Review Protocol

Run three review passes, then synthesize findings.

Pass 1: Engineering Pushback

Review the PRD as if you're an engineer who has to build this.

CHECK for:
- Vague requirements that could be interpreted multiple ways
- Features that sound simple but have hidden complexity
- Missing edge cases (empty states, error handling, concurrent users)
- Scope that's too large for the stated timeline
- Dependencies on external services or data that aren't addressed
- Non-functional requirements that are missing or unrealistic
- Features listed without clear acceptance criteria

FLAG each issue as:
  [BLOCKER] — Cannot start building without this resolved
  [CONCERN] — Should be addressed but won't stop work
  [SUGGESTION] — Would improve the PRD but not critical

Pass 2: User Reality Check

Review the PRD as if you're the target user described in the document.

CHECK for:
- Does the problem statement ring true? Would a real person describe it this way?
- Are there user stories that no real user would care about?
- Is there a clear path from "I have this problem" to "this product solves it"?
- Are there features that solve the builder's problem, not the user's problem?
- Would the success metrics actually matter to users?
- If this is an AI product: would users trust the AI in this context?

FLAG each issue with the same severity levels.

Pass 3: Product Strategy Check

Review the PRD as a product leader who's seen products fail.

CHECK for:
- Is the problem validated with real users, or is it assumed?
- Is the product differentiated from competitors, or is it a me-too?
- Is v1 scope achievable, or is it trying to do everything at once?
- Are the success metrics leading indicators, or will you only know
  if it worked 6 months too late?
- Are the assumptions documented and testable?
- Is there a clear "why now?" — what's the window of opportunity?
- Are there risks that could kill the product that aren't mentioned?

FLAG each issue with the same severity levels.

Synthesis

After all three passes, compile a review summary:

PRESENT to user:

"Here's my review of the PRD from three perspectives:

**Engineering Pushback** (X issues)
[list BLOCKER and CONCERN items]

**User Reality Check** (X issues)
[list BLOCKER and CONCERN items]

**Product Strategy Check** (X issues)
[list BLOCKER and CONCERN items]

**Suggestions for Improvement**
[list SUGGESTION items across all passes]

Would you like me to address any of these? I can update the PRD
to resolve the blockers and concerns."

Iteration Loop

WHILE user has feedback:
  APPLY requested changes to PRD.md
  IF changes are significant (new features, changed scope, new user):
    RE-RUN the relevant review pass
  PRESENT updated PRD

MAX 3 iteration rounds. After 3 rounds:
  INFORM user: "The PRD has been through multiple rounds of refinement.
  I recommend finalizing it and starting the technical spec — you can
  always update the PRD as you learn more."

Output

The final reviewed PRD.md is saved to the project root. Any review notes are saved to _prd/review-notes.md for reference.

# Review Notes

## Review Date
{date}

## Blockers Resolved
- {issue → resolution}

## Concerns Addressed
- {issue → resolution}

## Accepted Risks
- {issue the user chose to accept, and why}

## Open Items Deferred
- {item deferred to post-launch or next version}

SAVE review notes to _prd/review-notes.md.