# Prd Writing

> Write a product requirements document (PRD) that captures problem, goal, scope, approach, and risk. Use whenever the user mentions PRD, product requirements, product doc, product brief, requirements doc, or needs to write a structured document about what to build and why.

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

---


# prd-writing

a prd is a thinking artifact. its job is to make a decision auditable, not to satisfy a template.

## what a good prd does

- forces a clear statement of the problem
- names the user and the evidence they have this problem
- defines what success looks like in measurable terms
- bounds scope by naming what's in and what's deliberately out
- exposes risks and bets

## what a bad prd does

- describes the solution as if the problem were settled
- pads with sections that nobody reads
- uses success metrics that are vanity (page views, signups)
- avoids the question "what could kill this?"

## the structure to start from

```
# [feature name]

## context
two sentences. what's happening in the world or in our product that makes this worth doing now.

## problem
who feels it.
what specifically.
how we know (evidence: research, support tickets, analytics, sales feedback).
what they do today and why it falls short.

## goal
the job-to-be-done framing: "when [situation], i want to [motivation], so i can [outcome]".
primary success metric: one number, with target and timeframe.
secondary metrics: 1-2 that we'd watch but won't optimize for.
guardrail metrics: things we don't want to break.

## scope
in scope: bullets.
out of scope: bullets. be explicit about what we are choosing not to do.
alternatives considered: each with one sentence on why we didn't pick it.

## approach
the shape of the solution at a level a designer and engineer can react to.
user flow (described in prose or steps).
key screens or surfaces.
data shape.
states to handle: loading, empty, error, success.

## open questions
what we don't know yet.
who can answer.
when we need the answer by.

## risks
what could kill this.
what we're explicitly betting on.
what we'd learn first if we did a smaller version.

## timeline (only if needed)
milestones, not gantt charts.
```

## rules

- write in present tense.
- name a real user, not a persona.
- use numbers where you have them. when you don't, write "no evidence yet, validate before build".
- one prd, one feature. don't bundle.
- length is the wrong metric. clarity is.

## what to do before sharing

- read it from the perspective of someone who hasn't been in the conversation. does the problem stand on its own?
- read it from the perspective of an engineer. is the scope answerable?
- read it from the perspective of a skeptic. what would they push back on?