| name | prd-review |
| description | Use this skill when the user has an existing PRD, product spec, one-pager, or PR/FAQ and wants critique, approval-readiness review, quality-bar scoring, required changes, or a red-team pass. Trigger on phrases like "review this PRD", "critique my product spec", "is this PRD ready", "PRD quality bar", "red-team this requirements doc", "find gaps in this PR/FAQ", or "what would block approval". Do NOT trigger for drafting a new PRD from an idea (use prd-writer), converting an approved PRD into an agentic implementation plan (use prd-to-plan), building a roadmap (use roadmap), or ranking multiple initiatives (use prioritization).
|
| allowed-tools | ["Read","Write","Edit","Grep","Glob","Bash","AskUserQuestion"] |
| mutating | true |
| version | 1.0.0 |
| disable-model-invocation | false |
PRD Review
Contract
Run a structured critique loop against an existing product requirements artifact.
The job is to decide whether the PRD is ready for product, design, engineering,
data, GTM, legal, or executive review, and to name the concrete changes required
to make it decision-ready.
Hard gates:
- If no PRD/spec/brief exists, stop and route to
prd-writer; do not invent the
document being reviewed.
- Do not mark a PRD ready when the problem, primary user, decision, success
metric, or non-goals are missing. Return
DONE_WITH_CONCERNS or
NEEDS_CONTEXT.
- Do not silently rewrite the PRD unless the user explicitly asks for edits.
Default output is a findings artifact with suggested wording and patch-ready
changes.
- Do not approve legal, compliance, security, accessibility, or data-governance
posture. Identify risks and escalation owners.
Evidence requirements:
- Inspect the supplied PRD and any referenced research, analytics, tickets,
designs, support notes, prior PRDs, meeting notes, or decision logs.
- Every finding must cite a section, heading, line, source path, or explicit
absence. Unsupported criticism is not a finding.
- Separate facts verified in source material from reviewer judgment. Mark weak
evidence as
[ASSUMPTION], [NEEDS EVIDENCE], or [NEEDS OWNER].
- For standard/deep reviews, score the PRD against problem clarity, user
specificity, evidence quality, goals/non-goals, requirements testability,
success metrics, tradeoffs, rollout, risks, and decision readiness.
Artifact paths and naming:
- Write review artifacts to the first existing parent, creating the final
directory if needed:
workspace/product/reviews/ then product/reviews/.
- Filename:
YYYYMMDD-HHMMSS-prd-review-<slug>.md.
- If the user only wants inline feedback, return the same structure in chat and
set
Artifact: none - returned inline.
Workflow
- Classify mode.
quick: narrow review of one section or one approval concern.standard: full PRD quality review and required-change list.deep: high-risk, regulated, multi-team, executive, or launch-critical PRD.edit-pass: user asked for direct revisions in addition to findings.
- Identify the review target. Resolve the source PRD path or supplied text,
title, owner, status, audience, and the decision the review should unblock.
If the target is ambiguous, ask once with
AskUserQuestion when available.
- Build an evidence pack. Read the PRD, referenced artifacts, nearby docs,
analytics, customer evidence, support/sales notes, and prior decisions. Record
what was inspected and what was missing.
- Run the quality gate. Check for the five readiness blockers first:
problem, user, decision, success metric, non-goals. If any are absent, lead
with those blockers before lower-severity polish.
- Review section by section. Evaluate context, problem, goals, users, use
cases, requirements, metrics, tradeoffs, risks, rollout, open questions, and
appendices. Assign severity:
P0: blocks approval or could cause the team to build the wrong thing.P1: material ambiguity, missing evidence, or unowned risk.P2: useful improvement that changes execution quality.P3: clarity, wording, or hygiene.
- Recommend the path to approval. State the smallest set of changes that
would move the PRD to the next review state, plus owner/date suggestions when
evidence supports them.
- Write or return the artifact. Save the review when durable output was
requested or the review is substantial. Re-read any file written and ensure
every finding has evidence and a fix.
Output Format
Use this artifact structure:
# PRD Review: <prd title>
**Source PRD:** <path or supplied text>
**Review mode:** quick | standard | deep | edit-pass
**Decision being unblocked:** <decision>
**Overall verdict:** Ready | Ready with changes | Not ready | Needs context
**Confidence:** High | Medium | Low
## Evidence Used
## Readiness Gate
| Gate | Status | Evidence | Required fix |
| --- | --- | --- | --- |
| Problem | Pass/Fail/Partial | <citation> | <fix> |
| User | Pass/Fail/Partial | <citation> | <fix> |
| Decision | Pass/Fail/Partial | <citation> | <fix> |
| Success metric | Pass/Fail/Partial | <citation> | <fix> |
| Non-goals | Pass/Fail/Partial | <citation> | <fix> |
## Findings
| ID | Severity | Section | Evidence | Why it matters | Recommended fix |
| --- | --- | --- | --- | --- | --- |
## Quality Bar Scorecard
## Required Changes Before Approval
## Suggested Edits
## Open Questions
## Approval Path
Close every run with:
Status: DONE | DONE_WITH_CONCERNS | BLOCKED | NEEDS_CONTEXT
Artifact: <path or "none - returned inline">
Verdict: Ready | Ready with changes | Not ready | Needs context
Required changes: <count>
Evidence used: <source list>
Residual risk: <none or concise list>
Next skill: prd-writer | prd-to-plan | roadmap | prioritization | none
Status meanings:
DONE: review completed, evidence inspected, and no P0/P1 findings remain.DONE_WITH_CONCERNS: review completed but approval is qualified by missing
evidence, unresolved P0/P1 findings, or specialist escalation.BLOCKED: source PRD or required files are inaccessible.NEEDS_CONTEXT: the review target, audience, or approval decision is unclear
after one clarification pass.
Anti-Patterns
- Reviewing a PRD that has not been provided.
- Treating grammar cleanup as product review.
- Saying "looks good" without section-level evidence.
- Rewriting the PRD without preserving the critique and rationale.
- Inventing user evidence, metrics, owners, dates, or regulatory conclusions.
- Marking approval-ready while P0/P1 findings remain open.
- Letting the existing solution frame hide a weak or missing problem statement.
