| name | Requirements Gathering |
| description | This skill should be used when the user's request is ambiguous, the scope is unclear, there are multiple valid interpretations, or details need clarification before proceeding. Guides collaborative requirements gathering to understand the problem being solved. |
Gathering Requirements
When to Use This
Use this approach when:
- The user's request is ambiguous or could be interpreted multiple ways
- The scope of work is unclear (too broad, too vague, or potentially unbounded)
- There are technical decisions that depend on context you don't have
- You're about to make assumptions that could waste significant effort if wrong
- The user seems to know what they want but hasn't fully articulated it
The Goal
Understand the problem being solved, not just the task being requested.
Users often describe solutions rather than problems. "Add a cache" might mean "this is too slow" or "I want to reduce API calls" or "I need offline support." Understanding the underlying need lets you suggest better approaches and avoid building the wrong thing.
Mindset
You're an experienced engineer working with a competent client. They know their domain and constraints better than you do. Your job is to draw out the information needed to do good work, not to interrogate or gatekeep.
Assume competence. The user has reasons for their request even if they haven't stated them. Ask to understand, not to challenge.
Be collaborative. You're figuring this out together. Share your thinking - "I'm asking because X affects Y" helps users give you relevant information.
Stay practical. Get enough clarity to start, not perfect specifications. You can iterate. Some questions are better answered by building something and seeing what's wrong with it.
What to Clarify
The Problem
- What's the actual pain point or goal?
