breakdown-feature-prd
Verifiedby github · Updated Apr 16, 2026
Prompt for creating Product Requirements Documents (PRDs) for new features, based on an Epic.
See It In Action
Let me explore the codebase first and then use the PRD skill.
Great context. I have everything needed — the epic PRD, feature brief, and an existing PRD (tooltip tours) to match the format. Let me generate the onboarding checklist PRD now.
Let me read the key documents to build the PRD.
Now I have everything. Let me create the PRD, resolving the open questions with product-reasonable defaults so eng can estimate today.
PRD is written at docs/ways-of-work/plan/Activation/self-serve-onboarding-checklist/prd.md.
Here's what I resolved from the open questions in Marco's feature brief:
| Open Question | Decision | Rationale |
|---|---|---|
| Dismissible or forced? | Dismissible with confirmation + re-accessible from Settings | Respects user autonomy; avoids frustration while keeping a path back |
| Progress bar or checkmarks? | Both — progress bar at top + checkmarks per item | Progress bar drives momentum; checkmarks give per-item status |
| Completion reward? | Confetti animation, auto-hide after 5s | Lightweight positive reinforcement; no badge/gamification complexity in v1 |
| UI placement? | Collapsible right sidebar panel (bottom sheet on mobile) | Non-intrusive, persistent, and responsive |
| Invited team members? | Shorter 3-step variant (skip project creation + invite) | Their admin already set up the workspace |
The PRD includes 8 user stories, detailed functional/non-functional requirements, 12 acceptance criteria in Given/When/Then format, and a clear Out of Scope section. It follows the same structure as the tooltip tours PRD so the format is familiar to the team.
Worth flagging to Marco: I made reasonable product calls on all 5 open questions so eng can estimate today, but he should validate these decisions — especially the dismissibility model and the invited-member variant scope — before Sprint 15 kicks off.
Permissions
| Scope | Description |
|---|---|
| filesystem:write |
SKILL.md
Feature PRD Prompt
Goal
Act as an expert Product Manager for a large-scale SaaS platform. Your primary responsibility is to take a high-level feature or enabler from an Epic and create a detailed Product Requirements Document (PRD). This PRD will serve as the single source of truth for the engineering team and will be used to generate a comprehensive technical specification.
Review the user's request for a new feature and the parent Epic, and generate a thorough PRD. If you don't have enough information, ask clarifying questions to ensure all aspects of the feature are well-defined.
Output Format
The output should be a complete PRD in Markdown format, saved to /docs/ways-of-work/plan/{epic-name}/{feature-name}/prd.md.
PRD Structure
1. Feature Name
- A clear, concise, and descriptive name for the feature.
2. Epic
- Link to the parent Epic PRD and Architecture documents.
3. Goal
- Problem: Describe the user problem or business need this feature addresses (3-5 sentences).
- Solution: Explain how this feature solves the problem.
- Impact: What are the expected outcomes or metrics to be improved (e.g., user engagement, conversion rate, etc.)?
4. User Personas
- Describe the target user(s) for this feature.
5. User Stories
- Write user stories in the format: "As a
<user persona>, I want to<perform an action>so that I can<achieve a benefit>." - Cover the primary paths and edge cases.
6. Requirements
- Functional Requirements: A detailed, bulleted list of what the system must do. Be specific and unambiguous.
- Non-Functional Requirements: A bulleted list of constraints and quality attributes (e.g., performance, security, accessibility, data privacy).
7. Acceptance Criteria
- For each user story or major requirement, provide a set of acceptance criteria.
- Use a clear format, such as a checklist or Given/When/Then. This will be used to validate that the feature is complete and correct.
8. Out of Scope
- Clearly list what is not included in this feature to avoid scope creep.
Context Template
- Epic: [Link to the parent Epic documents]
- Feature Idea: [A high-level description of the feature request from the user]
- Target Users: [Optional: Any initial thoughts on who this is for]
FAQ
What does breakdown-feature-prd do?
Prompt for creating Product Requirements Documents (PRDs) for new features, based on an Epic.
When should I use breakdown-feature-prd?
Use it when you need a repeatable workflow that produces text report.
What does breakdown-feature-prd output?
In the evaluated run it produced text report.
How do I install or invoke breakdown-feature-prd?
Ask the agent to use this skill when the task matches its documented workflow.
Which agents does breakdown-feature-prd support?
Agent support is inferred from the source, but not explicitly declared.
What tools, channels, or permissions does breakdown-feature-prd need?
It uses no extra tools; channels commonly include text; permissions include filesystem:write.
Is breakdown-feature-prd safe to install?
Static analysis marked this skill as medium risk; review side effects and permissions before enabling it.
How is breakdown-feature-prd different from an MCP or plugin?
A skill packages instructions and workflow conventions; tools, MCP servers, and plugins are dependencies the skill may call during execution.
Does breakdown-feature-prd outperform not using a skill?
About breakdown-feature-prd
When to use breakdown-feature-prd
When a team has an epic and needs a detailed feature-level PRD. When engineering needs clear requirements, user stories, and acceptance criteria before implementation. When a feature request is underspecified and should be refined through clarifying questions.
When breakdown-feature-prd is not the right choice
When the task is to implement code rather than write planning documentation. When there is no epic or feature context available and the user does not want to provide clarification.
What it produces
Produces text report.