Requirements elicitation through structured interviewing. Use when: (1) User provides vague, ambiguous, or incomplete requirements, (2) Clarification is needed before building features or writing code, (3) User says 'build X' without specifying behavior, edge cases, or constraints, (4) Translating stakeholder requests into PRDs, specs, or user stories. Triggers on phrases like 'make it better', 'add a feature', 'fix this', 'I need something that...', or any request lacking concrete acceptance criteria.
Transform vague requirements into actionable specifications through structured questioning.
Past behavior over future intentions. Never ask "Would you use X?" — ask "Tell me about the last time you tried to solve this." Ground every discussion in concrete past experiences.
Problems over solutions. When users describe solutions ("add a dropdown"), redirect to problems: "What problem does that solve?" and "What would that enable you to do?"
Specifics over generalities. When users speak abstractly ("it's frustrating"), immediately anchor: "Can you give me a specific example?" or "When did that last happen?"
One question at a time. Never overwhelm with multiple questions. Ask the most important question, wait for the answer, then follow up.
Start broad, understand the landscape:
- "What are you trying to accomplish?"
- "Walk me through what happens today when you [do this task]."
- "What triggered this request? What happened recently?"
Confirm the problem exists and matters:
- "How are you solving this today?"
- "What's the hardest part about that?"
- "What have you already tried?"
- "How much time/money does this cost you?"
Identify boundaries and requirements:
- "Who else uses this? Who else is affected?"
- "What would a successful outcome look like?"
- "What would make this a failure?"
- "Are there any technical/business/time constraints I should know about?"
- "What's definitely out of scope?"
Surface hidden complexity:
- "What happens when [X goes wrong]?"
- "What's the most unusual case you've encountered?"
- "Are there exceptions to how this normally works?"
- "What happens if [user does unexpected thing]?"
Distinguish must-haves from nice-to-haves:
- "If you could only have one thing, what would it be?"
- "What would you cut if we had half the time?"
- "Is this blocking something else?"
Use these when responses are vague or incomplete:
| Technique | When to Use | Example |
|---|---|---|
| Echo probe | Encourage elaboration | "It felt 'clunky'?" |
| Specificity probe | Vague statement | "Can you give me a specific example?" |
| Contrast probe | Unclear criteria | "What would good vs bad look like?" |
| Why probe | Surface motivation | "Why is that important?" |
| Consequence probe | Understand impact | "What happens if we don't do this?" |
Five Whys: For root cause analysis, ask "Why?" iteratively (usually 3-5 times) until you reach the underlying need.
Real interest manifests as:
Warning signs of unclear requirements:
When you have sufficient clarity, produce the appropriate artifact or hand off to a downstream workflow:
User Stories - For discrete implementable units:
As a [user type], I want to [action] so that [benefit].
Acceptance Criteria:
- Given [context], when [action], then [result]
- Given [context], when [action], then [result]
Technical Spec - For implementation-focused requirements. See references/tech-spec-template.md
PRD Handoff - For formal PRDs, use the workflow-create-prd skill using the insights gathered here.
Before generating output, verify:
| Situation | Start With |
|---|---|
| "Build me X" | "What problem does X solve for you?" |
| "Make it better" | "Better in what way? What's not working now?" |
| "Like [competitor]" | "What specifically about [competitor] do you want?" |
| "It's broken" | "Walk me through what happened." |
| "Add a feature" | "What would that feature let you do that you can't do now?" |
| User describes solution | "Interesting—what problem are you trying to solve?" |
| User can't articulate | "Can you show me how you do this today?" |
references/tech-spec-template.md - Technical specification templatereferences/question-bank.md - Extended question library by categoryreferences/failure-modes.md - Common requirements gathering failures and how to avoid themThis skill is upstream of the workflow-create-prd skill. Once the interview is complete and requirements are clarified:
workflow-create-prd to formalize the requirements into a structured PRD.Technical Spec template for implementation-focused requirements when a full PRD is not necessary.