Product Requirement Document (PRD) Skill
This skill helps you write well-structured and logically clear Product Requirement Documents (PRD). A PRD is the core blueprint of a product — it tells us *why* we are building this product and *what* features it should have.
Why Do We Need a PRD?
- Align Goals: Ensure developers, designers, and stakeholders share a common understanding of the product.
- Reduce Ambiguity: Transform vague ideas into concrete requirements through clear text and diagrams.
- Serve as Test Baseline: The Acceptance Criteria in the PRD serve as the basis for QA testing.
PRD Core Components
A complete PRD typically contains the following sections:
- Background & Goals: Why are we doing this? What problem are we solving? What are the success metrics?
- User Stories: Who are the users? What do they want to do? What is their purpose?
- Functional Requirements: Specific descriptions of system behavior.
- Non-Functional Requirements: Performance, security, reliability constraints.
- UI/UX Flow: Page flow diagrams, wireframes, or mockup links.
- Analytics: What user behavior data needs to be tracked?
- Out of Scope: Clearly define what is *not* included to prevent scope creep.
How to Use This Skill
When a user presents a vague idea (e.g., "I want a feature that allows users to share bookmarks"), follow these steps:
- Initial Interview: Ask the user key questions (Who, Why, What).
- Drafting: Use
template_comprehensive.md(full version) ortemplate_simple.md(simple version) to draft the PRD. - Review: Have the user review the draft to confirm it meets expectations.
- Finalize: Once finalized, this PRD becomes the input for subsequent SA (System Analysis) and implementation phases.
Tips & Best Practices
- Use Clear Language: Avoid vague words like "might", "should"; use precise terms like "shall/must", "can".
- Use Diagrams: Use flowcharts (Mermaid) to supplement text descriptions.
- Keep It Updated: PRD is a Living Document — if requirements change, update the PRD accordingly.