requirements-analysis skill

---
name: requirements-analysis
description: 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.
allowed-tools: Read, Write, Edit, Task, TodoWrite, Grep, Glob
---

# 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](template.md). Use this structure exactly.

**To write template to spec directory:**
1. Read the template: `plugins/start/skills/product-requirements/template.md`
2. 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:**
1. Have I identified ALL activities needed for this section?
2. Have I launched parallel specialist agents to investigate?
3. Have I updated the PRD according to findings?
4. Have I presented COMPLETE agent responses to the user?
5. 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](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](examples/good-prd.md) for reference on well-structured PRDs.