# Prd Builder

> Opinionated PRD generator that forces a TL;DR, hypothesis + counter-hypothesis, explicit Out-of-scope cuts with reasoning, and a mandatory 3-question intake when the brief is a one-liner. Use instead of generic PRD generators when you want a doc that fights back against vague asks - the 3-question intake and counter-hypothesis are non-negotiable here. Triggers on phrases like "draft a PRD with hypothesis and metrics", "PRD that pushes back on vague asks", "structured product spec from fuzzy ask", "PRD for X", "feature spec for X", "turn this into a PRD I can react to", "напиши PRD по фиче X", "сделай спеку с гипотезой".

- Skill: `euroconic/prd-builder` (Agent Skill)
- Install (CLI): `npx skillmds@latest add euroconic/prd-builder`
- Raw SKILL.md: https://api.skillmd.com/api/skills/euroconic/prd-builder/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-builder

---


# PRD Builder

## Purpose

Most PRDs fail in the first 30 seconds because the reader can't tell what problem they solve, for whom, and how success will be measured. This skill produces a PRD where those answers are front-loaded and every section pulls weight.

This is for **product PRDs** (consumer or B2B SaaS framing). For enterprise B2B delivery specs (use cases, FRD, traceability), use a BA-style spec writer instead.

## When to use

- Feature ask from leadership ("we should do X") with no underlying spec
- Fuzzy problem from a stakeholder that needs structure before discussion
- Drafting a PRD to circulate for reactions, not a final delivery contract
- Turning your own thinking into a doc others can poke at

## When NOT to use

- For detailed engineering specs (architecture, API contracts)
- For one-line tickets in a sprint
- When the problem is unclear and needs discovery first (run `deep-market-research` or `synthetic-user-interview` first)

## Inputs

Required:
- Problem statement, feature ask, or short description

Optional but strongly improves output:
- Target user / persona
- Current workflow being replaced or augmented
- Business context (strategy, OKRs this serves)
- Known constraints (tech, legal, timeline)
- Adjacent features or systems

If only a one-liner is given, ask **three sharp questions** before writing:
1. Who hurts today and how do they currently cope?
2. What outcome would tell us this worked?
3. What's the hardest tradeoff you already see?

Do not write the PRD until these have at least rough answers.

## Process

### Phase 1: Frame the problem

- One-paragraph problem statement in plain language
- Current state: what the user does today, with friction
- Why now: what changed in market, tech, or business to make this worth doing now

### Phase 2: Hypothesis

- "We believe that [change] will result in [outcome] for [user/business]"
- Why this hypothesis is non-obvious (if it's obvious, the doc isn't worth writing)
- Counter-hypothesis: what would we expect to see if we're wrong

### Phase 3: Solution sketch

- What it is, in 3-5 bullets max
- What it is NOT (boundary clarity)
- Optional: 2-3 alternatives considered and why rejected

### Phase 4: Scope

Three explicit lists:
- **Must**: in scope for v1
- **Nice**: nice to have, cut if needed
- **Out**: explicitly not in scope, with one-line reasoning

If "Out" is empty, the scope is undefined.

### Phase 5: Success metrics

- **North metric**: the one number that proves this worked
- **Input metrics**: what we'd see moving first if it's working
- **Guardrail metrics**: what should NOT get worse (regressions to watch)
- Each metric with a directional target ("up", "down 20%", "above baseline")

Vague metrics ("improve engagement") are not allowed.

### Phase 6: Open questions and assumptions

- 3-7 open questions where the PRD is making assumptions
- For each: what we're assuming, why we're assuming it, what would change if wrong

### Phase 7: Risks and tradeoffs

- Top 3 things that could kill this
- Top 3 second-order effects (what changes in adjacent systems)
- Explicit tradeoff: what are we choosing not to optimize

## Output

```
# PRD: [Feature name]

**Author**: [user]  |  **Status**: Draft  |  **Date**: [today]

## TL;DR (3 sentences max)
## Problem
## Hypothesis
## Solution sketch
## Scope: Must / Nice / Out
## Success metrics
## Open questions
## Risks and tradeoffs
## Appendix: discarded alternatives
```

The TL;DR is non-optional and must work as a standalone summary. If a reader stops after TL;DR, they should still know what's being proposed and why.

## Common failure modes to avoid

- **Solution before problem**: writing the spec before the problem is sharp
- **Vague metrics**: "improve UX", "drive growth" - useless without numbers
- **Empty "Out" section**: scope without explicit cuts isn't scope
- **Missing open questions**: every PRD has assumptions. Hiding them doesn't make them less risky.
- **No tradeoff**: a PRD that claims pure upside is lying to itself

## Recommended companion

Run `prd-critic` on the output before sharing with eng or exec. The pair catches what either alone misses.