How do I install the Prd Writing skill?

Run npx skillmds@latest add dragoon0x/prd-writing in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Prd Writing safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Prd Writing?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Prd Writing free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Prd Writing?

dragoon0x (@dragoon0x) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Prd Writing by dragoon0x — Agent Skill

Name: Prd Writing
Author: dragoon0x

Prd Writing

Write product requirement documents that engineers want to read and can actually build from. Covers structure, scope discipline, and the balance between clarity and over-specification. Use when writing PRDs, reviewing spec quality, or when engineering keeps asking clarifying questions.

dragoon0x f9dc50c 2.5 KB Updated Sep 17, 2026

File contents

PRD Writing

Write PRDs that communicate intent, scope, and constraints without over-specifying implementation.

How to use

/prd-writing Apply PRD constraints to this conversation.
/prd-writing <feature> Draft or review a PRD for the described feature.

Constraints

Problem First

MUST start with the problem, never the solution
Problem statement MUST be understandable by someone who just joined the team in under 60 seconds
MUST include user evidence (data, quotes, support tickets) not just PM intuition
NEVER jump to features without establishing why this matters

Structure

One-pager format for smaller features: problem, proposed solution, success metrics, scope boundaries, open questions
Full PRD for larger initiatives: background, problem with evidence, goals, user stories, requirements, scope in/out, design considerations, rollout plan, risks
Apply the "so what" test to every section: if removing it wouldn't confuse the engineer, cut it
NEVER exceed 3 pages unless the initiative genuinely requires it. Length is not thoroughness.

Scope Discipline

MUST include an explicit "out of scope" section
SHOULD answer "is this essential for v1?" for every requirement
MUST flag scope creep when requirements expand beyond the original problem
NEVER let scope grow without re-evaluating timeline and resources

Success Metrics

MUST define 1-3 concrete, measurable outcomes
Each metric MUST specify: what you'll measure, how, target, and evaluation timeline
"Improve user experience" is not a metric. "Reduce task completion time by 20%" is.
NEVER ship without knowing how you'll measure whether it worked

Engineering Empathy

Define what, not how. NEVER prescribe implementation details.
MUST respect the reader's time — engineers are busy
SHOULD surface edge cases, failure states, and unusual inputs
MUST keep the document updated as scope evolves. PRDs are living documents.

Anti-Patterns

The Novel: 15-page PRDs nobody reads past page 2
Solution-first: jumping to features without the problem
Implementation prescription: telling engineers which API to use
The Static Artifact: writing once and never updating as scope changes
Vague metrics that can't fail ("make it better")

---name: prd-writingdescription: Write product requirement documents that engineers want to read and can actually build from. Covers structure, scope discipline, and the balance between clarity and over-specification. Use when writing PRDs, reviewing spec quality, or when engineering keeps asking clarifying questions.---# PRD WritingWrite PRDs that communicate intent, scope, and constraints without over-specifying implementation.## How to use- `/prd-writing` Apply PRD constraints to this conversation.- `/prd-writing <feature>` Draft or review a PRD for the described feature.## Constraints### Problem First- MUST start with the problem, never the solution- Problem statement MUST be understandable by someone who just joined the team in under 60 seconds- MUST include user evidence (data, quotes, support tickets) not just PM intuition- NEVER jump to features without establishing why this matters### Structure- One-pager format for smaller features: problem, proposed solution, success metrics, scope boundaries, open questions- Full PRD for larger initiatives: background, problem with evidence, goals, user stories, requirements, scope in/out, design considerations, rollout plan, risks- Apply the "so what" test to every section: if removing it wouldn't confuse the engineer, cut it- NEVER exceed 3 pages unless the initiative genuinely requires it. Length is not thoroughness.### Scope Discipline- MUST include an explicit "out of scope" section- SHOULD answer "is this essential for v1?" for every requirement- MUST flag scope creep when requirements expand beyond the original problem- NEVER let scope grow without re-evaluating timeline and resources### Success Metrics- MUST define 1-3 concrete, measurable outcomes- Each metric MUST specify: what you'll measure, how, target, and evaluation timeline- "Improve user experience" is not a metric. "Reduce task completion time by 20%" is.- NEVER ship without knowing how you'll measure whether it worked### Engineering Empathy- Define what, not how. NEVER prescribe implementation details.- MUST respect the reader's time — engineers are busy- SHOULD surface edge cases, failure states, and unusual inputs- MUST keep the document updated as scope evolves. PRDs are living documents.### Anti-Patterns- The Novel: 15-page PRDs nobody reads past page 2- Solution-first: jumping to features without the problem- Implementation prescription: telling engineers which API to use- The Static Artifact: writing once and never updating as scope changes- Vague metrics that can't fail ("make it better")

Frequently asked questions