Intro in this page language first. The official description stays in its original wording; we do not rewrite SKILL.md.
What it does
Prompt for creating Product Requirements Documents (PRDs) for new features, based on an Epic.
When to use it
The official description does not include a separate “Use when”. Per the spec, agents activate this skill when the task matches keywords in that description.
How agents load it
Per Agent Skills progressive disclosure: name and description load at startup (~100 tokens); the full SKILL.md body loads when the skill activates; scripts/, references/, and assets/ load only as needed. This file's sections: Feature PRD Prompt; Goal; Output Format; PRD Structure; Context Template.
File analysis
File analysis: instruction-only skill (SKILL.md). The agent loads the full body when activated.
Choose the target agent and installation scope, keep referenced package files, then verify the skill appears in the client's catalog.
Ask your Agent to install
Copy these instructions to a compatible agent and confirm the target directory matches your client.
Install the agent skill "breakdown-feature-prd" into my project. The full SKILL.md and official description are at https://zicq.com/en/skills/skl-9acf87e7a4d229dc-Breakdown-Feature-Prd.html
Save it as .cursor/skills/breakdown-feature-prd/SKILL.md or .claude/skills/breakdown-feature-prd/SKILL.md and keep the frontmatter name and description exactly as-is.
The CLI lets you choose the agent interactively. The default scope is the project; use -g for user scope. Confirm package availability with the discovery command, then use npx skills list to inspect installed skills.
Readable layout
---
name: breakdown-feature-prd
description: 'Prompt for creating Product Requirements Documents (PRDs) for new features, based on an Epic.'
---
# 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 ``, I want to `` so that I can ``."
- 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]