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-33description: 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<!-- Generated from harness/github-copilot/plugins/project-planning/skills/breakdown-feature-prd/SKILL.md by harness/claude-code/scripts/convert_from_copilot.py. Edit the source, not this file. -->78# Feature PRD910Transform 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.1112## When to invoke1314- "Create a PRD for this feature from the parent epic."15- "Write `/docs/ways-of-work/plan/{epic-name}/{feature-name}/prd.md`."16- "Turn this feature idea into user stories and acceptance criteria."17- "Break this epic enabler into a feature Product Requirements Document."1819## Product context2021| Input | How to use it |22| --- | --- |23| Epic | Link or reference the parent Epic PRD and Architecture documents. Preserve scope and constraints. |24| Feature Idea | Convert it into a clear problem, solution, user value, and requirements. |25| Target Users | Use provided personas; if absent, infer cautiously and mark assumptions. |26| Engineering downstream | Write requirements precise enough to generate a comprehensive technical specification. |2728Do 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.2930## PRD structure3132| Section | Required content | Quality bar |33| --- | --- | --- |34| Feature Name | Clear, concise, descriptive feature name. | Names user-visible capability or technical enabler. |35| Epic | Link to parent Epic PRD and Architecture documents. | Uses stable paths or titles provided by the user. |36| Goal | Problem, Solution, and Impact. | Problem is 3-5 sentences; Impact names expected metrics such as user engagement or conversion rate. |37| User Personas | Target users. | Includes goals, pain points, permissions, or context when known. |38| 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. |39| Requirements | Functional and Non-Functional Requirements. | Specific, unambiguous, testable, and scoped to this feature. |40| Acceptance Criteria | Checklist or Given/When/Then per story or major requirement. | Validates complete and correct behavior. |41| Out of Scope | Explicit exclusions. | Prevents scope creep and clarifies handoffs. |4243## Requirement writing rules4445| Requirement type | Include | Avoid |46| --- | --- | --- |47| Functional Requirements | User-visible behaviors, system actions, permissions, data changes, integrations, edge cases. | Vague verbs such as "support" without observable behavior. |48| Non-Functional Requirements | Performance, security, accessibility, data privacy, reliability, auditability, operational constraints. | Generic quality claims with no threshold or acceptance signal. |49| 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. |50| Out of Scope | Deferred features, excluded personas, unsupported platforms, non-goals. | Hidden assumptions that engineering must discover later. |5152## Output template5354```markdown55# <Feature Name> PRD5657## 1. Feature Name58<clear feature name>5960## 2. Epic61- Epic PRD: <link or title>62- Epic Architecture: <link or title>6364## 3. Goal65**Problem:** <3-5 sentences describing the user problem or business need>66**Solution:** <how the feature solves the problem>67**Impact:** <expected outcomes or metrics, such as user engagement or conversion rate>6869## 4. User Personas70- <persona>: <goal, context, or need>7172## 5. User Stories73- As a `<user persona>`, I want to `<perform an action>` so that I can `<achieve a benefit>`.7475## 6. Requirements76### Functional Requirements77- <specific behavior>7879### Non-Functional Requirements80- <performance, security, accessibility, data privacy, reliability, or operational constraint>8182## 7. Acceptance Criteria83- [ ] Given <context>, when <action>, then <observable result>.8485## 8. Out of Scope86- <excluded work>8788## Assumptions and open questions89- <only when needed>90```9192## Quality gate9394- [ ] The output is suitable for `/docs/ways-of-work/plan/{epic-name}/{feature-name}/prd.md`.95- [ ] The PRD links or names the parent Epic PRD and Architecture documents.96- [ ] Problem, Solution, and Impact are all present.97- [ ] User stories use the required "As a... I want... so that..." format.98- [ ] Functional and Non-Functional Requirements are specific, unambiguous, and testable.99- [ ] Acceptance Criteria cover primary paths and edge cases.100- [ ] Out of Scope is explicit enough to prevent scope creep.
paulasilvatech