| name | create-requirements |
| description | Create a PRD / product requirements document with app summary, design principles, and detailed requirements. |
| disable-model-invocation | true |
| allowed-tools | Read, Write, Glob |
Write Product Requirements Document
Create or update a product requirements document that serves as the source of truth for product behavior and functionality.
Document Structure
The document must contain exactly three sections:
- App Summary - Brief overview (what, who, where)
- Design Principles - 3-5 high-level principles guiding the design
- Requirements - Comprehensive functional and non-functional requirements
Requirements for App Summary
- Single paragraph describing core function
- Target users and use cases
- Platform and context (device types, environments)
- Keep under 10 bullet points total
Requirements for Design Principles
- 3-5 principles maximum
- Each principle: short heading + 3-5 bullets
- Capture the "why" behind design decisions
- Examples: Accessibility First, Cognitive Simplicity, Deliberate Safety
Requirements for Requirements Section
Functional Requirements
Must capture:
- All user-facing features and behaviors
- All UI screens and their states
- All user interactions and their outcomes
- Data and content (categories, options, fixed values)
- Error handling and edge cases
Organization:
- Group by feature area (FR1, FR2, FR3...)
- Sub-number within features (FR1.1, FR1.2...)
- Use descriptive headings
Non-Functional Requirements
Must capture:
- Platform constraints (OS, device types, orientation)
- Accessibility requirements (touch targets, contrast, cognitive load, motor control)
- Interaction constraints (input methods, complexity limits)
- Performance and reliability expectations
State Diagrams
Required:
- Include 1+ Mermaid state diagrams showing state transitions
- Diagram user interactions triggering state changes
- Show relationships between independent state machines
- Add notes for important behaviors
Example:
stateDiagram-v2
[*] --> StateA: User action
StateA --> StateB: Condition met
StateB --> StateA: User action
note right of StateA
Important behavior
or constraint
end note
User Interface
Describe:
- Screen layouts (text description, no ASCII art)
- Component visual design (colors, icons, labels where essential)
- Component states (default, selected, disabled, etc.)
- Layout proportions where they affect functionality
User Interactions
Document:
- Interaction sequences (step-by-step)
- Timing where it affects UX
- What persists vs what clears
- State preservation across actions
Critical Constraints
What to EXCLUDE
- Implementation details (no code files, component names, class names)
- Build/deployment information
- Technology stack specifics
- File structures
- "Excluded features" or "out of scope" sections
- ASCII/text-based UI diagrams (use Mermaid or text descriptions)
- Version number and last updated date
Level of Detail Rules
Include style details ONLY when essential for functionality:
- ✅ "YES button is green with checkmark icon" (color conveys meaning)
- ✅ "High contrast throughout" (accessibility requirement)
- ✅ "Minimum 72dp touch targets" (accessibility requirement)
- ✅ "Long-press for 1.5 seconds to unlock" (functional requirement)
Exclude style details that are implementation minutiae:
- ❌ "Border stroke width is 4dp"
- ❌ "Animation duration is 300ms"
- ❌ "Font size is 36sp"
- ❌ "Padding is 24dp"
- ❌ Hex color values (#FF5733)
Rule of thumb: If changing the detail would NOT significantly change functionality or user experience, exclude it.
What to INCLUDE
Current state only:
- Document behavior as it currently exists
- No alternatives, no "could do X or Y"
- No future enhancements or roadmap
- No design rationale in requirements (put rationale in Design Principles)
Complete behavior:
- Every user action and system response
- Every UI state and transition
- Every error condition
- Every persistence rule
Writing Style
- Use bulleted lists over prose
- One concept per bullet point
- Imperative for requirements ("App must...", "User can...")
- Declarative for states ("Button is green", "Sidebar appears")
- Concise language, no filler words
- High information density
Document Optimization
- Optimize for AI agent consumption
- Maximize clarity and token efficiency
- Each section provides unique information (no redundancy)
- Keep document under 600 lines where possible
- Use Mermaid diagrams to replace lengthy text descriptions
Output
Save the document with:
- Filename:
PRODUCT_REQUIREMENTS.md
- Location: Project root or
docs/ directory
- Format: Markdown with Mermaid diagrams
Validation Checklist
Before finalizing, verify:
$ARGUMENTS
