Feature PRD
Transform a high-level feature or enabler from an Epic into a well-defined, detailed Markdown PRD for a large-scale SaaS platform that becomes the single source of truth for engineering and downstream technical specifications.
When to invoke
- "Create a PRD for this feature from the parent epic."
- "Write
/docs/ways-of-work/plan/{epic-name}/{feature-name}/prd.md."
- "Turn this feature idea into user stories and acceptance criteria."
- "Break this epic enabler into a feature Product Requirements Document."
Product context
| Input |
How to use it |
| Epic |
Link or reference the parent Epic PRD and Architecture documents. Preserve scope and constraints. |
| Feature Idea |
Convert it into a clear problem, solution, user value, and requirements. |
| Target Users |
Use provided personas; if absent, infer cautiously and mark assumptions. |
| Engineering downstream |
Write requirements precise enough to generate a comprehensive technical specification. |
Do not leave major ambiguity hidden. If information is missing and no interaction is possible, add an Assumptions or Open Questions subsection inside the relevant PRD section.
PRD structure
| Section |
Required content |
Quality bar |
| Feature Name |
Clear, concise, descriptive feature name. |
Names user-visible capability or technical enabler. |
| Epic |
Link to parent Epic PRD and Architecture documents. |
Uses stable paths or titles provided by the user. |
| Goal |
Problem, Solution, and Impact. |
Problem is 3-5 sentences; Impact names expected metrics such as user engagement or conversion rate. |
| User Personas |
Target users. |
Includes goals, pain points, permissions, or context when known. |
| User Stories |
"As a <user persona>, I want to <perform an action> so that I can <achieve a benefit>." |
Covers primary paths and edge cases. |
| Requirements |
Functional and Non-Functional Requirements. |
Specific, unambiguous, testable, and scoped to this feature. |
| Acceptance Criteria |
Checklist or Given/When/Then per story or major requirement. |
Validates complete and correct behavior. |
| Out of Scope |
Explicit exclusions. |
Prevents scope creep and clarifies handoffs. |
Requirement writing rules
| Requirement type |
Include |
Avoid |
| Functional Requirements |
User-visible behaviors, system actions, permissions, data changes, integrations, edge cases. |
Vague verbs such as "support" without observable behavior. |
| Non-Functional Requirements |
Performance, security, accessibility, data privacy, reliability, auditability, operational constraints. |
Generic quality claims with no threshold or acceptance signal. |
| Acceptance Criteria |
Given/When/Then or checklist statements tied to a requirement; preserve the Given/When/Then. notation when requested. |
Criteria that merely restate the requirement. |
| Out of Scope |
Deferred features, excluded personas, unsupported platforms, non-goals. |
Hidden assumptions that engineering must discover later. |
Output template
# <Feature Name> PRD
## 1. Feature Name
<clear feature name>
## 2. Epic
- Epic PRD: <link or title>
- Epic Architecture: <link or title>
## 3. Goal
**Problem:** <3-5 sentences describing the user problem or business need>
**Solution:** <how the feature solves the problem>
**Impact:** <expected outcomes or metrics, such as user engagement or conversion rate>
## 4. User Personas
- <persona>: <goal, context, or need>
## 5. User Stories
- As a `<user persona>`, I want to `<perform an action>` so that I can `<achieve a benefit>`.
## 6. Requirements
### Functional Requirements
- <specific behavior>
### Non-Functional Requirements
- <performance, security, accessibility, data privacy, reliability, or operational constraint>
## 7. Acceptance Criteria
- [ ] Given <context>, when <action>, then <observable result>.
## 8. Out of Scope
- <excluded work>
## Assumptions and open questions
- <only when needed>
Quality gate
1---2name: breakdown-feature-prd-23description: Create a detailed feature Product Requirements Document from an epic and feature idea, including goal, personas, user stories, functional and non-functional requirements, acceptance criteria, and out-of-scope boundaries. Use when asked to write a feature PRD or docs/ways-of-work feature prd.md.4---56# Feature PRD78Transform a high-level feature or enabler from an Epic into a well-defined, detailed Markdown PRD for a large-scale SaaS platform that becomes the single source of truth for engineering and downstream technical specifications.910## When to invoke1112- "Create a PRD for this feature from the parent epic."13- "Write `/docs/ways-of-work/plan/{epic-name}/{feature-name}/prd.md`."14- "Turn this feature idea into user stories and acceptance criteria."15- "Break this epic enabler into a feature Product Requirements Document."1617## Product context1819| Input | How to use it |20| --- | --- |21| Epic | Link or reference the parent Epic PRD and Architecture documents. Preserve scope and constraints. |22| Feature Idea | Convert it into a clear problem, solution, user value, and requirements. |23| Target Users | Use provided personas; if absent, infer cautiously and mark assumptions. |24| Engineering downstream | Write requirements precise enough to generate a comprehensive technical specification. |2526Do not leave major ambiguity hidden. If information is missing and no interaction is possible, add an Assumptions or Open Questions subsection inside the relevant PRD section.2728## PRD structure2930| Section | Required content | Quality bar |31| --- | --- | --- |32| Feature Name | Clear, concise, descriptive feature name. | Names user-visible capability or technical enabler. |33| Epic | Link to parent Epic PRD and Architecture documents. | Uses stable paths or titles provided by the user. |34| Goal | Problem, Solution, and Impact. | Problem is 3-5 sentences; Impact names expected metrics such as user engagement or conversion rate. |35| User Personas | Target users. | Includes goals, pain points, permissions, or context when known. |36| User Stories | "As a `<user persona>`, I want to `<perform an action>` so that I can `<achieve a benefit>`." | Covers primary paths and edge cases. |37| Requirements | Functional and Non-Functional Requirements. | Specific, unambiguous, testable, and scoped to this feature. |38| Acceptance Criteria | Checklist or Given/When/Then per story or major requirement. | Validates complete and correct behavior. |39| Out of Scope | Explicit exclusions. | Prevents scope creep and clarifies handoffs. |4041## Requirement writing rules4243| Requirement type | Include | Avoid |44| --- | --- | --- |45| Functional Requirements | User-visible behaviors, system actions, permissions, data changes, integrations, edge cases. | Vague verbs such as "support" without observable behavior. |46| Non-Functional Requirements | Performance, security, accessibility, data privacy, reliability, auditability, operational constraints. | Generic quality claims with no threshold or acceptance signal. |47| Acceptance Criteria | Given/When/Then or checklist statements tied to a requirement; preserve the `Given/When/Then.` notation when requested. | Criteria that merely restate the requirement. |48| Out of Scope | Deferred features, excluded personas, unsupported platforms, non-goals. | Hidden assumptions that engineering must discover later. |4950## Output template5152```markdown53# <Feature Name> PRD5455## 1. Feature Name56<clear feature name>5758## 2. Epic59- Epic PRD: <link or title>60- Epic Architecture: <link or title>6162## 3. Goal63**Problem:** <3-5 sentences describing the user problem or business need>64**Solution:** <how the feature solves the problem>65**Impact:** <expected outcomes or metrics, such as user engagement or conversion rate>6667## 4. User Personas68- <persona>: <goal, context, or need>6970## 5. User Stories71- As a `<user persona>`, I want to `<perform an action>` so that I can `<achieve a benefit>`.7273## 6. Requirements74### Functional Requirements75- <specific behavior>7677### Non-Functional Requirements78- <performance, security, accessibility, data privacy, reliability, or operational constraint>7980## 7. Acceptance Criteria81- [ ] Given <context>, when <action>, then <observable result>.8283## 8. Out of Scope84- <excluded work>8586## Assumptions and open questions87- <only when needed>88```8990## Quality gate9192- [ ] The output is suitable for `/docs/ways-of-work/plan/{epic-name}/{feature-name}/prd.md`.93- [ ] The PRD links or names the parent Epic PRD and Architecture documents.94- [ ] Problem, Solution, and Impact are all present.95- [ ] User stories use the required "As a... I want... so that..." format.96- [ ] Functional and Non-Functional Requirements are specific, unambiguous, and testable.97- [ ] Acceptance Criteria cover primary paths and edge cases.98- [ ] Out of Scope is explicit enough to prevent scope creep.
paulasilvatech