Breakdown Feature Prd
Turn an Epic-level feature idea into a structured PRD your agent and engineers can implement from.
Overview
Breakdown Feature PRD is an agent skill most often used in Validate (also Build) that turns an Epic-linked feature request into a detailed SaaS PRD Markdown file.
Install
npx skills add https://github.com/github/awesome-copilot --skill breakdown-feature-prdWhat is this skill?
- Expert PM persona for large-scale SaaS feature breakdown
- Structured PRD template: goal, personas, user stories, and Epic linkage
- Clarifying-questions loop when Epic context is thin
- Output path convention: `/docs/ways-of-work/plan/{epic-name}/{feature-name}/prd.md`
- Designed as single source of truth ahead of a technical specification
- PRD structure with numbered sections including Feature Name, Epic, Goal, Personas, and User Stories
Adoption & trust: 9.4k installs on skills.sh; 34.6k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You have an Epic-level feature idea but no shared PRD with problem, personas, stories, and success metrics for your agent or team to execute against.
Who is it for?
Solo SaaS builders breaking one Epic feature into a reviewable PRD before coding or agent implementation.
Skip if: Features that already have an approved PRD and frozen requirements—skip and move to technical spec or implementation skills.
When should I use this skill?
You need a detailed PRD for a new feature based on a parent Epic and may lack full context.
What do I get? / Deliverables
You get a complete `prd.md` under your docs plan path that can feed technical specifications and downstream implementation planning.
- Markdown PRD at `/docs/ways-of-work/plan/{epic-name}/{feature-name}/prd.md`
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Canonical shelf is Validate because the skill’s job is to define problem, solution, personas, and stories before committing engineering effort—classic scoping work. Scope subphase fits Epic-to-feature decomposition and measurable impact framing, not implementation.
Where it fits
Define problem, solution, and impact for a billing Epic feature before estimating build.
Capture monetization-related stories and metrics in the PRD while scoping a paid tier feature.
Refresh personas and acceptance-oriented stories when an agent picks up mid-sprint work.
Align launch checklist items with PRD goals and measurable impact before release comms.
How it compares
Use instead of unstructured chat PRDs when you need a fixed template and on-disk artifact for the whole journey.
Common Questions / FAQ
Who is breakdown-feature-prd for?
Solo and indie SaaS builders (and small teams) who work from Epics and need a formal PRD before engineering or agent implementation.
When should I use breakdown-feature-prd?
In Validate when scoping a new feature from an Epic; in Build when refreshing PM docs for an in-flight initiative; whenever problem, personas, or stories are still incomplete.
Is breakdown-feature-prd safe to install?
It is primarily a drafting workflow that writes local Markdown; review the Security Audits panel on this page and your repo paths before running in production monorepos.
SKILL.md
READMESKILL.md - Breakdown Feature Prd
# 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]