review-prd

Files (1)

• SKILL.md

SKILL.md (first lines)

# Reviewing a PRD

Evaluate a PRD for quality — not agreement with a preferred solution.

## HARD-GATE
- Review the document, not the idea.
- Every finding must cite a specific PRD section (redact sensitive data).
- No alternative solutions unless a requirement is infeasible.

## Core Process
1. Receive the PRD.
2. Apply the review checklist (completeness, testability, clarity, feasibility, scope, dependencies, edge cases).
3. Classify each finding as Critical, Suggestion, or Note.
4. Produce a findings table with severity, evidence, and recommendation.
5. Verdict: Approved / Approved with Suggestions / Needs Revision.
6. If Needs Revision, instruct author to address Critical findings and re-run review.

## Output
- Verdict.
- Findings table with columns: #, Severity, Section, Finding, Evidence, Recommendation.
- Summary with count by severity.
- Acknowledgement of well-written sections.

## Review Checklist (abbreviated)
**Completeness:** goals and success metrics are measurable; out-of-scope explicit.
**Testability:** requirements can be verified with pass/fail tests; acceptance criteria are specific.
**Clarity:** no undefined jargon; no ambiguous modal verbs.
**Feasibility:** timeline realistic; dependencies identified.
**Scope & Edge Cases:** failure scenarios described; migration/compatibility concerns.

Refer to the full checklist in the skill’s reference documentation.

## Integration
| Skill | When |
|-------|------|
| `create-prd` | Review after drafting |
| `plan-tickets` | Draft tracker-ready tickets after review passes |
| `work-router` with `tech-lead` intent | Add a feasibility focus to the review; it does not select a separate persona |

From igmarin/agnostic-planning-skills, MIT.

More from igmarin/agnostic-planning-skills