Prd writing

Skill Dragoon0x/studio/skills/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.From its SKILL.md

Install

npx -y skills add Dragoon0x/studio --skill prd-writing

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

2 stars2 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

2.7 KB, as published. Nobody here has run it

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?