Requirements Gathering

requirements.md

allowed-tools	description
Write TodoWrite	Collaboratively gather requirements through conversation and generate a requirements.md document

Step 1: Initial feature understanding

1. Acknowledge the user's feature request
2. Provide a brief interpretation of what they want to build
3. Begin asking clarifying questions to understand:
   • The core problem this feature solves
   • Who will use this feature and why
   • The desired user experience and outcomes

Continue the conversation naturally until you have enough information to write comprehensive requirements.

Step 2: Iterative requirements discovery

Through conversational back-and-forth:

1. Identify user roles - Who interacts with this feature?
2. Understand user journeys - How do they use it from start to finish?
3. Explore edge cases - What could go wrong? What are the exceptions?
4. Clarify constraints - What limitations or rules apply?
5. Define success - What does "working well" mean for this feature?

Ask follow-up questions based on the user's responses. Dig deeper into areas that seem unclear or incomplete. Focus on understanding the "why" behind each requirement.

Step 3: Validate understanding

Once you believe you have sufficient information:

1. Provide a terse summary of the key requirements
2. List them as bullet points grouped by user role or feature area
3. Ask for confirmation: "Here's what I've understood... Is this complete and accurate?"
4. Iterate if the user adds, modifies, or corrects anything

Step 4: Generate requirements.md

After the user confirms the requirements are complete, create requirements.md:

# Project Requirements

## Overview
[Concise summary of the feature, its purpose, and primary value proposition]

## User Roles
[Define each identified user role/persona]

## Requirements

### Requirement 1: [Descriptive Title]

**User Story:** As a [role], I want [feature], so that [benefit]

**Acceptance Criteria:**
1. WHEN [trigger event] THEN the system SHALL [response]
2. IF [precondition] THEN the system SHALL [behavior]
3. WHILE [state] THE system SHALL [maintain behavior]
4. THE system SHALL [invariant behavior]

[Continue for each requirement...]

## Non-Functional Requirements

### Performance
[User-facing performance requirements]

### Usability
[Accessibility, error handling, user feedback requirements]

### Security
[Authentication, authorization, data protection requirements]

## Success Criteria
[Measurable outcomes indicating feature success]

## Out of Scope
[What is explicitly NOT included in this feature]

Step 5: Create next steps

Use TodoWrite to create a follow-up checklist:

- [ ] Review requirements with stakeholders
- [ ] Prioritize requirements for implementation
- [ ] Create technical design based on requirements
- [ ] Define test scenarios for each acceptance criterion

EARS Format Reference

Use these patterns for acceptance criteria:

• Event-driven: WHEN [event] THEN [system] SHALL [response]
• State-driven: WHILE [state] THE [system] SHALL [behavior]
• Conditional: IF [condition] THEN [system] SHALL [action]
• Feature-driven: WHERE [feature] THE [system] SHALL [capability]
• Invariant: THE [system] SHALL [always behavior]
• Complex: WHEN [event] AND [condition] THEN [system] SHALL [action] UNLESS [exception]

Key principles

• Keep asking questions until requirements are clear and complete
• Focus on WHAT users need, not HOW to implement
• Ensure each requirement is testable and measurable
• Use the user's own terminology
• Validate understanding before writing the document

$ARGUMENTS