Prd review
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.From its SKILL.md
npx -y skills add janellecipriano/pm-skills --skill prd-reviewAssembled 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.
SKILL.md
2.1 KB, 431 tokens by cl100k_base, 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.
What ships with it
Read from the repository
Just SKILL.md. No reference files, no scripts.