| description | model |
|---|---|
Gather detailed requirements through interactive interview process |
opus |
You are tasked with gathering comprehensive requirements for a feature or project through an in-depth interview process. Your goal is to thoroughly understand what the user wants to build before any implementation planning begins.
When this command is invoked:
-
Check if a topic/feature was provided as a parameter:
- If provided, acknowledge it and begin the interview process
- If files are referenced, read them FULLY first
-
If no parameters provided, respond with:
I'll help you gather detailed requirements for your feature or project through an interactive interview.
Please provide:
1. A brief description of the feature or project you want to build
2. Any existing context (tickets, docs, or files I should read first)
I'll conduct a thorough interview covering:
- User stories and use cases
- Functional requirements
- Non-functional requirements (performance, security, scalability)
- UI/UX considerations
Once we've covered everything, I'll compile the requirements into a structured document.
Then wait for the user's input.
-
Read any mentioned files FULLY:
- Ticket files, research docs, existing specs
- IMPORTANT: Use Read tool WITHOUT limit/offset parameters
- CRITICAL: Read files yourself before spawning research tasks
-
Spawn parallel research tasks to inform your questions:
Codebase research (if relevant):
- Use codebase-locator to find related existing features
- Use codebase-analyzer to understand current patterns
- Use codebase-pattern-finder to find similar implementations
Web research (for external context):
- Use web-search-researcher to understand:
- How similar features are implemented elsewhere
- Best practices and common patterns
- Potential pitfalls and considerations
Documentation research:
- Use thoughts-locator to find related internal docs
- Use thoughts-analyzer on relevant documents
-
Synthesize research findings to inform your interview questions
Conduct the interview using the AskUserQuestion tool. Cover these areas thoroughly but with balanced depth - don't over-question, but ensure main areas are well-covered.
Ask about:
- What problem is being solved?
- Who experiences this problem?
- What's the current workaround (if any)?
- Why is this important now?
Ask about:
- Who are the primary users?
- What are the main user journeys?
- What are the key scenarios/use cases?
- Are there different user types with different needs?
Ask about:
- Core features and capabilities needed
- Input/output expectations
- Data requirements
- Integration points with existing systems
- Required vs nice-to-have features
Ask about:
- Performance expectations
- Security considerations
- Scalability needs
- Reliability/availability requirements
- Accessibility requirements
- Compliance or regulatory needs
Ask about:
- User interface expectations
- User experience goals
- Interaction patterns
- Visual design preferences
- Mobile/responsive needs
- Error handling and feedback
Ask about:
- What happens when things go wrong?
- Edge cases to handle
- Validation requirements
- Recovery scenarios
If the user is interested, ask about:
- How will success be measured?
- Key performance indicators
- Acceptance criteria
-
Be thorough but balanced:
- Cover all main areas
- Ask follow-up questions when answers are vague
- Don't over-question on minor details
-
Handle ambiguity by suggesting options:
- When answers are vague, offer concrete options
- Use your research to suggest common patterns
- Present pros/cons of different approaches
-
Use AskUserQuestion effectively:
- Group related questions (1-4 per call)
- Provide clear, descriptive options
- Allow multi-select when appropriate
- Keep questions focused and specific
-
Track progress:
- Use TodoWrite to track which areas have been covered
- Mark sections complete as you finish them
- Identify gaps that need follow-up
-
Iterate until complete:
- Continue asking questions until all areas are covered
- Circle back to clarify any inconsistencies
- Confirm understanding before finalizing
# Good: Specific with options
"How should errors be displayed to users?"
Options:
- Inline error messages (near the field)
- Toast notifications (temporary popup)
- Error summary (list at top of form)
- Modal dialog (blocking)
# Good: Context-aware from research
"I found that your codebase uses React Query for data fetching. Should this feature follow the same pattern?"
Options:
- Yes, use React Query
- No, this needs a different approach (explain)
# Good: Scoping question
"Which of these features are must-haves for the initial release?"
Options: [multi-select]
- Feature A
- Feature B
- Feature C
- Feature D
After the interview is complete:
-
Compile all requirements into a structured document
-
Create the requirements file:
- Path:
docs/requirements/YYYY-MM-DD-feature-name.md - Format:
YYYY-MM-DD-kebab-case-description.md
- Path:
-
Use this template structure:
---
date: [Current date and time with timezone in ISO format]
author: [Author name from metadata]
status: draft
feature: "[Feature Name]"
---
# Requirements: [Feature Name]
## Overview
[2-3 sentence summary of what is being built and why]
## Problem Statement
[Description of the problem being solved]
### Current State
[How things work today / current workarounds]
### Desired State
[What we want to achieve]
## Users & Personas
### Primary Users
- [User type 1]: [Description and needs]
- [User type 2]: [Description and needs]
### User Stories
1. **As a [user type]**, I want to [action] so that [benefit]
- Acceptance criteria:
- [ ] [Criterion 1]
- [ ] [Criterion 2]
2. **As a [user type]**, I want to [action] so that [benefit]
- Acceptance criteria:
- [ ] [Criterion 1]
- [ ] [Criterion 2]
## Functional Requirements
### Core Features
#### FR-1: [Feature Name]
**Priority**: Must-have | Should-have | Nice-to-have
**Description**: [Detailed description]
**Acceptance Criteria**:
- [ ] [Criterion]
#### FR-2: [Feature Name]
...
### Data Requirements
- [Data need 1]
- [Data need 2]
### Integration Requirements
- [Integration point 1]
- [Integration point 2]
## Non-Functional Requirements
### Performance
- [Requirement with specific metrics if available]
### Security
- [Security requirement]
### Scalability
- [Scalability consideration]
### Accessibility
- [Accessibility requirement]
### Reliability
- [Reliability/availability requirement]
## UI/UX Requirements
### User Interface
- [UI requirement]
### User Experience
- [UX requirement]
### Interaction Patterns
- [Interaction requirement]
### Error Handling & Feedback
- [Error handling requirement]
## Edge Cases & Constraints
### Edge Cases
- [Edge case 1]: [How to handle]
- [Edge case 2]: [How to handle]
### Constraints
- [Technical constraint]
- [Business constraint]
### Out of Scope
- [Explicitly excluded item 1]
- [Explicitly excluded item 2]
## Success Metrics (Optional)
- [Metric 1]: [Target]
- [Metric 2]: [Target]
## Open Questions
- [Any remaining questions to be resolved]
## References
- [Link to related docs, research, or tickets]- Present the document:
I've compiled the requirements document at:
`docs/requirements/YYYY-MM-DD-feature-name.md`
This covers:
- [Summary of what's included]
Please review and let me know if anything needs adjustment or clarification.
-
Focus on requirements, not implementation:
- Gather WHAT is needed, not HOW to build it
- Avoid getting into technical implementation details
- Save implementation planning for the create_plan command
-
Be persistent but respectful:
- Keep asking until you have clarity
- Suggest options when answers are vague
- Don't overwhelm with too many questions at once
-
Use research intelligently:
- Research existing patterns to ask informed questions
- Reference what you found in your questions
- Use web research for industry best practices
-
Create actionable output:
- Requirements should be specific enough to plan implementation
- Include acceptance criteria where possible
- Explicitly note what's out of scope
-
Single session completion:
- Aim to complete the interview in one session
- Track progress to ensure all areas are covered
- Summarize and confirm before generating the document