# Prd Critic

> Red-team a PRD by simulating a skeptical PM, a senior engineer, and a target customer ripping it apart before you ship it for review. Use after drafting a PRD and before sharing with eng leads, exec reviewers, or other stakeholders. Triggers on phrases like "critique this PRD", "review my PRD", "find holes in this spec", "what's wrong with this PRD", "stress-test my spec", "PRD red team", "разнеси мой PRD", "найди дыры в спеке".

- Skill: `euroconic/prd-critic` (Agent Skill)
- Install (CLI): `npx skillmds@latest add euroconic/prd-critic`
- Raw SKILL.md: https://api.skillmd.com/api/skills/euroconic/prd-critic/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Product & Planning
- Author: euroconic (https://skillmd.com/u/euroconic)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/euroconic/prd-critic

---


# PRD Critic

## Purpose

Most PRDs ship with the same five flaws: vague metrics, hidden assumptions, undefined scope, missing tradeoffs, and a solution that doesn't quite fit the problem. The author can't see them because they wrote them.

This skill puts the PRD through three hostile reviewers, each with a different angle, then consolidates a punch list of fixes.

Use this **before** sharing the PRD with your real eng lead, designer, or exec sponsor. It is cheaper to fix issues here than after political fallout.

## When to use

- You just drafted a PRD and are about to circulate it
- A teammate sent you a PRD and you want a second-opinion review
- Your exec keeps sending PRDs back and you want to pre-empt the same comments
- You're about to put a PRD into product review or sprint planning

## When NOT to use

- For documents that aren't PRDs (use `proofread` or general review instead)
- For PRDs at the discovery stage where structure is intentionally loose
- For ticket-level specs - the overhead isn't worth it

## Inputs

Required:
- PRD content (paste, markdown file, or path)

Optional:
- Specific angle to emphasize ("the eng lead is concerned about scope", "exec is skeptical about ROI")
- Target reviewer audience (helps tune severity)

## Process

### Phase 1: Three reviewers

Set up three reviewer personas explicitly. They argue in their own voice:

**The Skeptical PM** (Director-level, 10+ years)
- Pokes at strategic fit, prioritization, opportunity cost
- Standard moves: "why this instead of X?", "what does this displace?", "what's the second-order effect?"

**The Senior Engineer** (Staff+ engineer who has shipped at scale)
- Pokes at scope, complexity, technical assumptions, hidden integration cost
- Standard moves: "this is two features stapled together", "you're hiding a migration here", "what happens when X fails?"

**The Target Customer** (the actual user, in their voice)
- Pokes at value, workflow fit, why they would actually switch
- Standard moves: "I already have a way to do this", "this solves the wrong half of the problem", "I'd never pay for this without X"

Each reviewer reads the PRD and lists their top 3-5 concerns in their voice.

### Phase 2: Consolidation

Merge the three lists into a single ranked punch list:
- **Severity** (Critical / Major / Minor)
- **Source** (which reviewer raised it; if multiple, that's a signal)
- **What the issue is** (in plain language)
- **Why it matters** (the consequence if not fixed)
- **What to do** (concrete suggested edit)

### Phase 3: The five killer checks

Always run these five checks against the PRD even if no reviewer raised them:

1. **Vague metrics**: are success metrics directionally measurable with numbers?
2. **Empty Out-of-scope**: does the PRD say what is explicitly NOT being built?
3. **Hidden assumptions**: are key assumptions named or buried as fact?
4. **Missing tradeoffs**: does the PRD claim pure upside?
5. **Solution-problem fit**: would the solution actually solve the stated problem if shipped exactly as written?

If any check fails, add it to the punch list as Critical.

### Phase 4: Suggested rewrite (optional)

For the top 3 Critical issues, draft replacement language the author can paste in. Not a full rewrite - surgical edits.

## Output

```
# PRD Critique: [PRD title]

## TL;DR verdict (Ship / Revise / Rethink)

## Reviewer reactions
### Skeptical PM
### Senior Engineer
### Target Customer

## Killer checks (5/5)

## Punch list (ranked)
| # | Severity | Issue | Why it matters | Suggested fix |

## Suggested rewrites (top 3 Critical)

## What the PRD does well (do not cut these)
```

The final "does well" section is mandatory. A critique that only finds flaws gets dismissed. Naming what's already strong builds trust and prevents over-rewriting.

## Common failure modes to avoid

- **Surface-only feedback**: "improve clarity", "add metrics" - useless. Be specific or be quiet.
- **Reviewer drift**: each persona must stay in voice. The engineer doesn't care about brand consistency, the customer doesn't care about technical debt.
- **All-Critical inflation**: if everything is Critical, nothing is. Use the severity scale honestly.
- **Skipping the "does well" section**: this is where you signal you actually read the doc

## Pair with

Best used in tandem with `prd-builder`. Build → critique → revise → share. The whole loop runs in under an hour.