From mini-pm
Reviews product requirement documents (PRDs) against a structured checklist covering problem framing, customer validation, AI design, and success metrics.
How this skill is triggered — by the user, by Claude, or both
Slash command
/mini-pm:prd-review <PRD text or document><PRD text or document>The summary Claude sees in its skill listing — used to decide when to auto-load this skill
*Covers 2-pagers and 6-pagers. Mark each item ✅ (Yes) · ⚠️ (Partial) · ❌ (No)*
Covers 2-pagers and 6-pagers. Mark each item ✅ (Yes) · ⚠️ (Partial) · ❌ (No)
| Field | |
|---|---|
| Document Title | |
| Author / Reviewer | |
| Review Date |
Amazon PRFAQ principle: if the opening doesn't land, leadership stops reading. Check this first.
| # | Check | Status | Notes |
|---|---|---|---|
| 0.1 | Headline / title is a customer benefit statement — not a feature description or internal project name | ||
| 0.2 | First paragraph names the customer, the problem, and the transformation delivered — an unfamiliar exec understands why this matters in under 30 seconds | ||
| 0.3 | Document is free of buzzwords and hype: "revolutionary", "game-changing", "AI-powered", "next-gen", "paradigm shift" | ||
| 0.4 | Narrative is written from the customer's perspective throughout — not the engineer's or the company's |
Notes:
| # | Check | Status | Notes |
|---|---|---|---|
| 1.1 | Problem is clearly articulated (job-to-be-done) and validated with real customer data or research — not internal assumptions | ||
| 1.2 | Problem statement is a pure pain statement — does NOT hint at or imply a solution | ||
| 1.3 | Negative impact is quantified: time lost, cost, frequency, or scale of affected users | ||
| 1.4 | Customer persona defined with specific roles, industries, and needs; buyer vs. user distinguished if different | ||
| 1.5 | Urgency is clear — explains why now and the cost of inaction | ||
| 1.6 | Existing alternatives called out as insufficient, with a specific reason why they fall short | ||
| 1.7 | MOAT is defined and defensible — data flywheel, workflow lock-in, proprietary training, or switching cost | ||
| 1.8 | Solution is differentiated from ChatGPT, copilots, and commodity AI wrappers | ||
| 1.9 | Validated demand signal present — customer quotes, paid pilots, waitlists, or demonstrated willingness to pay |
Notes:
| # | Check | Status | Notes |
|---|---|---|---|
| 2.1 | Core value proposition is crisp (1–2 sentences) and directly addresses the stated problem | ||
| 2.2 | Solution addresses every problem raised in the Problem section — no orphaned pain points left unresolved | ||
| 2.3 | Solution is described in benefit language (what the customer experiences) — not feature lists or system architecture | ||
| 2.4 | Visual user flow included: input → processing → output | ||
| 2.5 | Core functional requirements listed in user story format | ||
| 2.6 | Use of Agentic AI / ML / LLMs justified over rule-based or simpler approaches; unstructured data types identified | ||
| 2.7 | AI drawbacks addressed: hallucination, attribution accuracy, agent failure modes, and explainability |
Notes:
| # | Check | Status | Notes |
|---|---|---|---|
| 3.1 | North Star metric defined — the single number that proves the product is working | ||
| 3.2 | Primary metric is customer-recognized — something the customer would care about, not an internal proxy | ||
| 3.3 | Every primary metric has a baseline (current state value) AND a SMART target (specific, time-bound) | ||
| 3.4 | Both leading indicators (early signals you can watch) and lagging indicators (ultimate business outcomes) are present | ||
| 3.5 | Secondary metrics included: adoption, time saved, cost reduction, or task completion rate | ||
| 3.6 | Anti-metrics / guardrails stated — what should NOT get worse (e.g. false attribution rate, user trust, latency) | ||
| 3.7 | Launch criteria clearly defined — what specific thresholds must be met to ship? | ||
| 3.8 | Metric ownership and tracking method defined — who owns each metric and how will it be measured? |
Notes:
| # | Check | Status | Notes |
|---|---|---|---|
| 4.1 | Agentic workflow broken into components (e.g. ingestion, extraction, summarization) with per-component risk assessment | ||
| 4.2 | ML feasibility, data availability, and accuracy expectations specified | ||
| 4.3 | Features prioritized by risk, cost, and value; MVP scope narrowed with rationale | ||
| 4.4 | Roadmap phases defined: MVP → MVP1 → Launch → Iteration, with feature sets and durations | ||
| 4.5 | Roadmap items linked back to priorities and risks |
Notes:
| # | Check | Status | Notes |
|---|---|---|---|
| 5.1 | AI performance evaluation approach described (datasets, ground truth sources, benchmarking cadence) | ||
| 5.2 | Accuracy targets defined relative to a human or rule-based baseline — not just in absolute terms | ||
| 5.3 | Prompting strategy described — few-shot, CoT, or conditional prompting where applicable | ||
| 5.4 | Plan for prompt iteration and improvement based on user feedback |
Notes:
| # | Check | Status | Notes |
|---|---|---|---|
| 6.1 | Risks assessed across Accountability, Transparency, Fairness, and Reliability | ||
| 6.2 | Human-in-the-loop and fallback paths planned | ||
| 6.3 | Sensitive use cases identified with mitigation strategies |
Notes:
| # | Check | Status | Notes |
|---|---|---|---|
| 7.1 | Development costs broken down (infra + manpower) and ongoing operational costs listed | ||
| 7.2 | Revenue scenarios defined and pricing model selected with rationale | ||
| 7.3 | Accuracy vs. cost tradeoffs explained | ||
| 7.4 | Directional pricing recommendation included |
Notes:
| Rating | ⬜ Strong ⬜ Good — minor gaps ⬜ Needs Work ⬜ Not Ready |
| Top Strengths | 1. · 2. · 3. |
| Top Gaps | 1. · 2. · 3. |
| Next Step |
PRD Review Checklist v3.0 — Reviews Project · Updated 2026-04-01 based on Amazon PRFAQ best practices
These items were added based on feedback patterns seen 5+ times across reviewed documents.
| ✦ NEW | Metrics & Success → 3.2 — Does each primary metric include a baseline (current state) and a SMART target? | | | (Added v2 — seen in 5 docs. Example: "When a document scopes the product too narrowly (e.g. "back-office teams in CRE ...") | | ✦ NEW | Problem & Customer → 1.1 — Is the problem backed by at least one concrete data point or direct customer evidence? | | | (Added v2 — seen in 5 docs. Example: "When a document scopes the product too narrowly (e.g. "back-office teams in CRE ...") |
Checklist v2 — pending approval from Mahesh
Creates, edits, and optimizes skills for Claude Code, including drafting, evaluating with test prompts, iterating on performance, and improving skill descriptions for better triggering accuracy.
npx claudepluginhub initmahesh/minipm --plugin mini-pm