Source profileQuality 64/100
github/awesome-copilot/skills/breakdown-feature-prd/SKILL.md
breakdown-feature-prd
Prompt for creating Product Requirements Documents (PRDs) for new features, based on an Epic.
- Source repository stars
- 37,126
- Declared platforms
- 0
- Static risk flags
- 0
- Last source update
- 2026-07-28
- Source checked
- 2026-07-28
Decision brief
What it does—and where it fits
Prompt for creating Product Requirements Documents (PRDs) for new features, based on an Epic.
Not for
- Tasks that require unconfirmed production actions or broad system permissions.
- Environments where the pinned source and install steps cannot be inspected.
Compatibility matrix
Platform support, with evidence labels
| Platform | Status | Evidence | What to check |
|---|---|---|---|
| Codex | Not declared | No explicit evidence | Portability before use |
| Claude Code | Not declared | No explicit evidence | Portability before use |
| Cursor | Not declared | No explicit evidence | Portability before use |
| Gemini CLI | Not declared | No explicit evidence | Portability before use |
Installation
Inspect first. Install second.
The source command is displayed only when detected. A safe inspection prompt is always available so your agent can explain every action before execution.
Source-detected install commandSource
npx skills add https://github.com/github/awesome-copilot --skill "skills/breakdown-feature-prd"Safe inspection promptEditorial
Inspect the Agent Skill "breakdown-feature-prd" from https://github.com/github/awesome-copilot/blob/9933dcad5be5caeb288cebcd370eeeb2fc2f1685/skills/breakdown-feature-prd/SKILL.md at commit 9933dcad5be5caeb288cebcd370eeeb2fc2f1685. List every install step, command, network request, credential, file read/write, external action, and rollback step. Explain whether it fits my task. Do not install or execute anything until I approve.
Workflow
What the source asks the agent to do
- 01
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…
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 w…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. - 02
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.
A clear, concise, and descriptive name for the feature.Link to the parent Epic PRD and Architecture documents.Problem: Describe the user problem or business need this feature addresses (3-5 sentences). - 03
PRD Structure
A clear, concise, and descriptive name for the feature.
A clear, concise, and descriptive name for the feature.Link to the parent Epic PRD and Architecture documents.Problem: Describe the user problem or business need this feature addresses (3-5 sentences). - 04
1. Feature Name
A clear, concise, and descriptive name for the feature.
A clear, concise, and descriptive name for the feature.- A clear, concise, and descriptive name for the feature.
Permission review
Static risk signals and limitations
No configured static risk pattern was detected
This is not proof of safety. Runtime behavior, indirect dependencies, and hidden external systems are outside the static scan.
Evidence record
Why each signal appears
EvidenceSourceComputedTestedEditorial
| Signal | Value | Evidence type | Meaning |
|---|---|---|---|
| Quality score | 64/100 | Computed | Documentation, specificity, maintenance, and trust rules |
| Repository stars | 37,126 | Source | Repository attention, not individual Skill quality |
| Compatibility | 0 platforms | Source | Declared in the catalog source record |
| Usage guide | automated source guide | Editorial | Generated or reviewed according to the visible evidence level |
Pinned source
Provenance and original SKILL.md
- Repository
- github/awesome-copilot
- Skill path
- skills/breakdown-feature-prd/SKILL.md
- Commit
- 9933dcad5be5caeb288cebcd370eeeb2fc2f1685
- License
- MIT
- Collected
- 2026-07-28
- Default branch
- main
View the original 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]