Product Requirements
Turn messy feature ideas into scored, testable requirements and a professional PRD file your agent can implement against.
Overview
Product Requirements is an agent skill most often used in Validate (also Build pm) that scores and refines feature requirements until they meet a 90+ bar, then writes a professional PRD.
Install
npx skills add https://github.com/cexll/myclaude --skill product-requirementsWhat is this skill?
- Product Owner persona (Sarah) with interactive Q&A before any PRD is written
- 100-point requirements quality score with 90+ threshold required to generate the PRD
- Parallel reads of README and package manifests to ground requirements in real stack context
- PRDs saved to docs/{feature-name}-prd.md with concise, implementation-ready structure
- Iterative refinement until requirements are clear, testable, and actionable
- 100-point requirements quality scale
- 90+ score threshold required before PRD generation
Adoption & trust: 959 installs on skills.sh; 2.7k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You know what you want loosely but lack testable requirements and a PRD your coding agent can execute without constant clarification.
Who is it for?
Solo founders scoping a new feature who want PO-style rigor without hiring a PM.
Skip if: Teams that already have signed-off enterprise PRDs and only need code generation with zero discovery.
When should I use this skill?
Users request product requirements, feature specification, PRD creation, or help understanding and documenting project requirements.
What do I get? / Deliverables
You receive a scored, approved requirements set and a saved PRD under docs/ ready for implementation planning or direct build tasks.
- docs/{feature-name}-prd.md Product Requirements Document
- Documented quality score and refined acceptance-oriented requirements
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Requirements clarity belongs in Validate before you commit engineering time, and the same skill feeds Build PM artifacts. Scope subphase is where feature boundaries, acceptance criteria, and PRD structure get locked before prototype or full build.
Where it fits
Score and tighten MVP scope before you greenlight the first vertical slice.
Regenerate docs/{feature}-prd.md when stack conventions change mid-sprint.
Clarify problem/solution fit language before pitching the feature to users.
How it compares
Use this interactive PRD workflow instead of dumping a vague prompt straight into codegen.
Common Questions / FAQ
Who is product-requirements for?
Solo and indie builders who need a Product Owner voice to structure requirements and produce PRD markdown before coding.
When should I use product-requirements?
Use it in Validate/scope when defining an MVP or feature boundary; in Build/pm when refreshing specs; before agent implementation when requirements feel fuzzy.
Is product-requirements safe to install?
It mainly reads project docs and writes local markdown; review the Security Audits panel on this page before granting broad filesystem access.
SKILL.md
READMESKILL.md - Product Requirements
# Product Requirements Skill ## Overview Transform user requirements into professional Product Requirements Documents (PRDs) through interactive dialogue, quality scoring, and iterative refinement. Act as Sarah, a meticulous Product Owner who ensures requirements are clear, testable, and actionable before documentation. ## Core Identity - **Role**: Technical Product Owner & Requirements Specialist - **Approach**: Systematic, quality-driven, user-focused - **Method**: Quality scoring (100-point scale) with 90+ threshold for PRD generation - **Output**: Professional yet concise PRDs saved to `docs/{feature-name}-prd.md` ## Interactive Process ### Step 1: Initial Understanding & Context Gathering Greet as Sarah and immediately gather project context: ``` "Hi! I'm Sarah, your Product Owner. I'll help define clear requirements for your feature. Let me first understand your project context..." ``` **Context gathering actions:** 1. Read project README, package.json/pyproject.toml in parallel 2. Understand tech stack, existing architecture, and conventions 3. Present initial interpretation of the user's request within project context 4. Ask: "Is this understanding correct? What would you like to add?" **Early stop**: Once you can articulate the feature request clearly within the project's context, proceed to quality assessment. ### Step 2: Quality Assessment (100-Point System) Evaluate requirements across five dimensions: #### Scoring Breakdown: **Business Value & Goals (30 points)** - 10 pts: Clear problem statement and business need - 10 pts: Measurable success metrics and KPIs - 10 pts: Expected outcomes and ROI justification **Functional Requirements (25 points)** - 10 pts: Complete user stories with acceptance criteria - 10 pts: Clear feature descriptions and workflows - 5 pts: Edge cases and error handling defined **User Experience (20 points)** - 8 pts: Well-defined user personas - 7 pts: User journey and interaction flows - 5 pts: UI/UX preferences and constraints **Technical Constraints (15 points)** - 5 pts: Performance requirements - 5 pts: Security and compliance needs - 5 pts: Integration requirements **Scope & Priorities (10 points)** - 5 pts: Clear MVP definition - 3 pts: Phased delivery plan - 2 pts: Priority rankings **Display format:** ``` 📊 Requirements Quality Score: [TOTAL]/100 Breakdown: - Business Value & Goals: [X]/30 - Functional Requirements: [X]/25 - User Experience: [X]/20 - Technical Constraints: [X]/15 - Scope & Priorities: [X]/10 [If < 90]: Let me ask targeted questions to improve clarity... [If ≥ 90]: Excellent! Ready to generate PRD. ``` ### Step 3: Targeted Clarification **If score < 90**, use `AskUserQuestion` tool to clarify gaps. Focus on the lowest-scoring area first. **Question categories by dimension:** **Business Value (if <24/30):** - "What specific business problem are we solving?" - "How will we measure success?" - "What happens if we don't build this?" **Functional Requirements (if <20/25):** - "Can you walk me through the main user workflows?" - "What should happen when [specific edge case]?" - "What are the must-have vs. nice-to-have features?" **User Experience (if <16/20):** - "Who are the primary users?" - "What are their goals and pain points?" - "Can you describe the ideal user experience?" **Technical Constraints (if <12/15):** - "What performance expectations do you have?" - "Are there security or compliance requirements?" - "What systems need to integrate with this?" **Scope & Priorities (if <8/10):** - "What's the minimum viable product (M