Prd review

Skill janellecipriano/pm-skills/skills/prd-review

Open-source Claude skills for Program Management in product development — charters, status reports, RAID logs, roadmaps, launch readiness, retros, postmortems, OKRs & more.

Install

npx -y skills add janellecipriano/pm-skills --skill prd-review

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Review a product requirements document (PRD) or spec against a quality checklist and surface gaps, ambiguities, and risks before engineering starts. Use when the user says "review this PRD", "is this spec ready", "critique my requirements", "PRD checklist", or shares a doc and wants it pressure-tested before build.

SKILL.md

2.1 KB, as published. Nobody here has run it

PRD Review

Pressure-test a PRD so problems are caught on the page, not in code. Be a constructive but skeptical reviewer.

When to use

A PRD/spec exists and the user wants feedback or a readiness check before build/estimation.

To author a PRD from scratch, use a PRD-drafting workflow; this skill reviews an existing one.

Review checklist

Assess the doc against each dimension. Quote or reference specifics; don't be generic.

Problem & why now — is the user problem clear and evidenced (not just a feature request)?
Audience — are target users/segments and their context defined?
Goals & success metrics — measurable outcomes, baseline → target? Anti-goals stated?
Scope — explicit in/out? MVP vs. later cuts clear?
Requirements — unambiguous, testable, prioritized (must/should/could)? No solution disguised as requirement.
UX — flows, key states (empty/error/loading/edge), accessibility considered?
Edge cases & failure modes — what happens when things go wrong?
Dependencies & constraints — other teams, platforms, legal/privacy, performance.
Risks & open questions — named, with owners.
Measurement — instrumentation/analytics plan to know if it worked.

Process

Read the PRD fully first.
Rate each dimension: ✅ solid / 🟡 needs work / 🔴 missing — with a one-line reason.
List the top gaps to fix before build, most important first.
Pose the open questions the author must answer to be buildable.
End with a verdict: Ready / Ready with fixes / Not ready.

Output format

A checklist table (dimension · rating · note), then Top gaps, Open questions, and the verdict. Be specific and kind; the goal is a better doc, not a teardown.