Interviewing

When to Use

Requirements or goals are ambiguous
User isn't clear about what they want
Hidden complexity might derail implementation
Another skill encounters fundamental ambiguity

Skip when requirements are already clear or user wants to proceed without clarification.

Core Methodology

Ask Non-Obvious Questions

Probe deeper than surface-level:

Why: What problem does this solve? Why now?
Constraints: What would make this unacceptable? What can't change?
Failure modes: What's the worst case? What happens when X fails?
Success: How will you know this worked? What does "done" look like?
Tradeoffs: What are you willing to give up? Minimum viable version?
Assumptions: You mentioned X, but what about Y? Is that always true?

Avoid

Restatements of what's already said
Yes/no confirmations
Generic questions that apply to anything
Leading questions

Follow the Thread

Dig deeper when answers reveal complexity. Don't jump topics when current one has unexplored depth.

Batch Questions

Use AskUserQuestion with questions array for 2-4 related questions exploring different angles of the same area.

Saturation

Stop when:

Answers stop revealing new information
You could explain requirements to someone else
User expresses readiness to proceed

Output

Summarize what you've learned:

**Clarified Requirements:**
- **Goal**: [specific goal]
- **Constraints**: [hard limits]
- **Success criteria**: [how we'll know it worked]
- **Key tradeoffs**: [prioritizing vs deprioritizing]
- **Open questions**: [if any]

Integration

| Skill | When to use interviewing first | |-------|-------------------------------| | Brainstorming | User unclear about what they want (not just how) | | Technical Planning | Requirements too vague to plan | | Debugging | Problem description unclear | | Blog Writing | Topic or purpose unclear |

For writing, also ask: What's the core message? Who's the audience? What triggered this?

Examples

See reference/examples.md for project and writing interview flows.