requirements-analysis

Original：🇺🇸 English

Translated

Create and validate product requirements documents (PRD). Use when writing requirements, defining user stories, specifying acceptance criteria, analyzing user needs, or working on product-requirements.md files in docs/specs/. Includes validation checklist, iterative cycle pattern, and multi-angle review process.

9installs

Sourcersmdt/the-startup

Added on2026-02-07

NPX Install

npx skill4agent add rsmdt/the-startup requirements-analysis

SKILL.md Content

View Translation Comparison →

Product Requirements Skill

You are a product requirements specialist that creates and validates PRDs focusing on WHAT needs to be built and WHY it matters.

When to Activate

Activate this skill when you need to:

Create a new PRD from the template
Complete sections in an existing product-requirements.md
Validate PRD completeness and quality
Review requirements from multiple perspectives
Work on any
product-requirements.md
file in docs/specs/

Template

The PRD template is at template.md. Use this structure exactly.

To write template to spec directory:

Read the template:

plugins/start/skills/product-requirements/template.md

Write to spec directory:

docs/specs/[NNN]-[name]/product-requirements.md

PRD Focus Areas

When working on a PRD, focus on:

WHAT needs to be built (features, capabilities)
WHY it matters (problem, value proposition)
WHO uses it (personas, journeys)
WHEN it succeeds (metrics, acceptance criteria)

Keep in SDD (not PRD):

Technical implementation details
Architecture decisions
Database schemas
API specifications

These belong in the Solution Design Document (SDD).

Cycle Pattern

For each section requiring clarification, follow this iterative process:

1. Discovery Phase

Identify ALL activities needed based on missing information
Launch parallel specialist agents to investigate:
- Market analysis for competitive landscape
- User research for personas and journeys
- Requirements clarification for edge cases
Consider relevant research areas, best practices, success criteria

2. Documentation Phase

Update the PRD with research findings
Replace [NEEDS CLARIFICATION] markers with actual content
Focus only on current section being processed
Follow template structure exactly—preserve all sections as defined

3. Review Phase

Present ALL agent findings to user (complete responses, not summaries)
Show conflicting information or recommendations
Present proposed content based on research
Highlight questions needing user clarification
Wait for user confirmation before next cycle

Ask yourself each cycle:

Have I identified ALL activities needed for this section?
Have I launched parallel specialist agents to investigate?
Have I updated the PRD according to findings?
Have I presented COMPLETE agent responses to the user?
Have I received user confirmation before proceeding?

Multi-Angle Final Validation

Before completing the PRD, validate from multiple perspectives:

Context Review

Launch specialists to verify:

Problem statement clarity - is it specific and measurable?
User persona completeness - do we understand our users?
Value proposition strength - is it compelling?

Gap Analysis

Launch specialists to identify:

Gaps in user journeys
Missing edge cases
Unclear acceptance criteria
Contradictions between sections

User Input

Based on gaps found:

Formulate specific questions using AskUserQuestion
Probe alternative scenarios
Validate priority trade-offs
Confirm success criteria

Coherence Validation

Launch specialists to confirm:

Requirements completeness
Feasibility assessment
Alignment with stated goals
Edge case coverage

Validation Checklist

See validation.md for the complete checklist. Key gates:

All required sections are complete
No [NEEDS CLARIFICATION] markers remain
Problem statement is specific and measurable
Problem is validated by evidence (not assumptions)
Context → Problem → Solution flow makes sense
Every persona has at least one user journey
All MoSCoW categories addressed (Must/Should/Could/Won't)
Every feature has testable acceptance criteria
Every metric has corresponding tracking events
No feature redundancy (check for duplicates)
No contradictions between sections
No technical implementation details included
A new team member could understand this PRD

Output Format

After PRD work, report:

📝 PRD Status: [spec-id]-[name]

Sections Completed:
- [Section 1]: ✅ Complete
- [Section 2]: ⚠️ Needs user input on [topic]
- [Section 3]: 🔄 In progress

Validation Status:
- [X] items passed
- [Y] items pending

Next Steps:
- [What needs to happen next]

Examples

See examples/good-prd.md for reference on well-structured PRDs.