---
name: product-requirements-document
description: "Enough detail that two engineers would build the same thing. Use when the user wants help with Product Requirements Document. Related topics: Product, Planning, Writing."
---

# Product Requirements Document

Enough detail that two engineers would build the same thing.

## How to use this skill

1. Ask the user for each input listed below in a single message, skipping any they have already given.
2. Where options are listed, offer them, but accept other answers too.
3. Fill the answers into the prompt template, then follow the completed prompt to produce the result.

## Inputs

- **What is wrong today** (longer free text)
- **Evidence** (longer free text)
- **Who is affected and roughly how many** (longer free text)
- **What we would build** (longer free text)
- **User-visible behaviour** (longer free text)
- **Edge cases and error states** (longer free text)
- **Explicitly out of scope** (longer free text)
- **Technical, legal, or dependency** (longer free text)
- **Deadline and what is driving it** (free text, e.g. "Date and why")
- **How we will know it worked** (free text, e.g. "Metric and target")
- **When we will check** (free text, e.g. "Date")

## Prompt template

# PRD

**Problem**
- What is wrong today: {{What is wrong today}}
- Evidence: {{Evidence}}
- Who is affected and roughly how many: {{Who is affected and roughly how many}}

**Solution**
- What we would build: {{What we would build}}
- User-visible behaviour: {{User-visible behaviour}}
- Edge cases and error states: {{Edge cases and error states}}
- Explicitly out of scope: {{Explicitly out of scope}}

**Constraints**
- Technical, legal, or dependency: {{Technical, legal, or dependency}}
- Deadline and what is driving it: {{Deadline and what is driving it}}

**Success**
- How we will know it worked: {{How we will know it worked}}
- When we will check: {{When we will check}}

Lead with the problem and the evidence, not the solution. If the evidence is thin, say so in the document rather than burying it.

Write the requirements as observable behaviour including the edge cases, because that is the part engineers otherwise have to invent. Say what happens to data that already exists.

Make the out-of-scope section prominent. It is the cheapest scope-argument prevention available. End with open questions, each with an owner and a date.

---

Source: [Product Requirements Document on PromptBuild](https://promptbuild.io/prompt/A9FrmPd3tZmp4QGHth6q/product-requirements-document)