Interviewing User for Requirements

Overview

Proactively surface and resolve ambiguities by systematically interviewing the user BEFORE implementation begins. This prevents wasted effort from incorrect assumptions.

Core principle: It's better to ask 5 questions upfront than to rewrite code 3 times.

Announce at start: "I'm using the ring:interviewing-user skill to gather requirements before we begin."

Quick Reference

Phase	Key Activities	Tool	Output
1. Context Analysis	Analyze task, identify ambiguities	Internal	Ambiguity inventory
2. Question Clustering	Group questions by category	Internal	Prioritized question list
3. Structured Interview	Ask questions using AskUserQuestion	AskUserQuestion	User responses
4. Understanding Summary	Synthesize and confirm	Text output	Validated Understanding
5. Proceed or Iterate	User confirms or clarifies	User input	Green light to proceed

The Process

Copy this checklist to track progress:

Interview Progress:
- [ ] Phase 1: Context Analysis (ambiguities identified)
- [ ] Phase 2: Question Clustering (questions prioritized)
- [ ] Phase 3: Structured Interview (questions asked and answered)
- [ ] Phase 4: Understanding Summary (presented to user)
- [ ] Phase 5: Proceed or Iterate (user confirmed)

Phase 1: Context Analysis

BEFORE asking any questions, analyze:

1. What the user explicitly stated - Extract concrete requirements
2. What the codebase implies - Patterns, conventions, existing solutions
3. What remains ambiguous - Gaps between stated and implied
4. What decisions I must make - Architecture, behavior, constraints

Create an Ambiguity Inventory:

Ambiguity Inventory:
- Architecture: [list unclear architectural decisions]
- Behavior: [list unclear behavioral requirements]
- Constraints: [list unclear constraints or limitations]
- Preferences: [list unclear user preferences]
- Integration: [list unclear integration points]

Phase 2: Question Clustering

Group questions by category and prioritize:

Priority	Category	Criteria
P0	Blocking	Cannot proceed without answer
P1	Architecture	Affects overall structure
P2	Behavior	Affects user-facing functionality
P3	Preferences	Affects style, not correctness

Question Budget:

• Maximum 4 questions per AskUserQuestion call (tool limitation)
• Maximum 3 rounds of questions (respect user's time)
• Prefer fewer, higher-quality questions

Phase 3: Structured Interview

Use AskUserQuestion tool with well-structured options:

Question Quality Checklist:

• Shows what I already know (evidence of exploration)
• Explains why I'm uncertain (the genuine conflict)
• Provides 2-4 concrete options with descriptions
• Options are mutually exclusive or clearly labeled as multi-select

Example - Good Question:

header: "Auth Method"
question: "The codebase has both session-based auth (UserService) and JWT (APIService). Which should this new endpoint use?"
options:
  - label: "Session-based (Recommended)"
    description: "Matches existing user-facing endpoints, simpler cookie handling"
  - label: "JWT tokens"
    description: "Matches API patterns, better for external integrations"
  - label: "Support both"
    description: "Maximum flexibility, more implementation complexity"

Example - Bad Question:

question: "What authentication should I use?"
options:
  - label: "Option 1"
  - label: "Option 2"

Phase 4: Understanding Summary

After gathering responses, synthesize into a Validated Understanding:

## Validated Understanding

### What We're Building
[1-2 sentence summary of the goal]

### Key Decisions Made
| Decision | Choice | Rationale |
|----------|--------|-----------|
| [Topic] | [Selected option] | [Why this was chosen] |

### Constraints Confirmed
- [Constraint 1]
- [Constraint 2]

### Out of Scope (Explicit)
- [Thing we're NOT doing]

### Assumptions (If Any)
- [Assumption]: [What would invalidate this]

Present this to the user for confirmation.

Phase 5: Proceed or Iterate

Confirmation Gate:

Understanding is NOT confirmed until user explicitly says:

• "Confirmed" / "Correct" / "That's right"
• "Proceed" / "Let's do it" / "Go ahead"
• "Yes" (in response to "Is this correct?")

These do NOT mean confirmation:

• Silence
• "Interesting" / "I see"
• Questions about the summary
• "What about X?" (that's requesting changes)

If not confirmed: Return to Phase 3 with targeted follow-up questions.

Question Categories

Architecture Questions

• "Which pattern should this follow: [A] or [B]?"
• "Where should this logic live: [Service A], [Service B], or new service?"
• "Should this be synchronous or asynchronous?"

Behavior Questions

• "When [edge case], should the system [A] or [B]?"
• "What should happen if [failure scenario]?"
• "Should users be able to [optional capability]?"

Constraint Questions

• "Is there a performance requirement for this?"
• "Does this need to support [specific scenario]?"
• "Are there backward compatibility requirements?"

Preference Questions

• "Do you prefer [verbose but explicit] or [concise but implicit]?"
• "Should I prioritize [speed] or [maintainability]?"
• "Any naming conventions I should follow?"

When to Auto-Trigger This Skill

Claude SHOULD invoke this skill automatically when:

1. Ambiguity count > 3 - More than 3 unclear decisions
2. Architecture choice unclear - Multiple valid patterns, no codebase precedent
3. User request is high-level - "Build me X" without specifics
4. Previous implementation was rejected - Indicates misunderstanding
5. Task spans multiple domains - Frontend + backend + infrastructure

Claude should NOT auto-trigger when:

• Task is a simple bug fix with clear reproduction
• User provided detailed specifications
• Following an existing plan
• Single question would suffice (use doubt-triggered-questions instead)

Anti-Patterns

Anti-Pattern	Why It's Wrong	Correct Approach
Asking without exploring first	Wastes user's time	Explore codebase THEN ask
Open-ended questions only	Hard to answer, vague responses	Provide concrete options
Too many questions at once	Overwhelming	Max 4 per round, max 3 rounds
Asking about things user already said	Shows you weren't listening	Re-read conversation first
Asking preferences when conventions exist	CLAUDE.md/codebase already answers	Follow existing patterns
Skipping summary phase	User can't correct misunderstandings	Always present Validated Understanding

Integration with Other Skills

Skill	Relationship
ring:doubt-triggered-questions	Use for single questions during work; use ring:interviewing-user for systematic upfront gathering
ring:brainstorming	Interview first to gather requirements, THEN brainstorm solutions
ring:writing-plans	Interview first to clarify scope, THEN create plan

Required Patterns

This skill uses these universal patterns:

• State Tracking: See skills/shared-patterns/state-tracking.md
• Failure Recovery: See skills/shared-patterns/failure-recovery.md
• Exit Criteria: See skills/shared-patterns/exit-criteria.md

Exit Criteria

Interview is complete when ALL of these are true:

• All P0 (blocking) questions answered
• All P1 (architecture) questions answered
• Validated Understanding presented
• User explicitly confirmed understanding
• No remaining ambiguities that affect correctness

Blocker Criteria

STOP and report if:

Decision Type	Blocker Condition	Required Action
Question Budget	Exceeded 3 rounds of questions without resolution	STOP and report - user may not have required information
Confirmation	User neither confirms nor denies understanding after 2 attempts	STOP and ask for explicit confirmation
Scope Creep	Interview reveals task is fundamentally different than expected	STOP and restart with new scope definition
Contradiction	User responses contradict each other	STOP and surface the contradiction for resolution

Cannot Be Overridden

The following requirements CANNOT be waived:

• MUST explore codebase before asking questions - asking without context wastes user time
• MUST provide concrete options (2-4 choices) - open-ended questions are FORBIDDEN
• MUST present Validated Understanding summary before proceeding
• CANNOT treat silence or ambiguous responses as confirmation

Severity Calibration

Severity	Condition	Required Action
CRITICAL	P0 blocking question unanswered	MUST resolve before any implementation
HIGH	P1 architecture question unanswered	MUST resolve - affects overall structure
MEDIUM	P2 behavior question unanswered	Should resolve - affects user-facing functionality
LOW	P3 preference question unanswered	Can proceed with sensible default

Pressure Resistance

User Says	Your Response
"Just start building, we'll figure it out"	"CANNOT proceed without resolving P0 and P1 questions. It's better to ask 5 questions upfront than rewrite code 3 times."
"I don't have time for all these questions"	"I MUST ask at least P0 blocking questions. Maximum 3 rounds, maximum 4 questions per round - this saves time versus incorrect implementation."
"You're the expert, just decide"	"CANNOT make architecture decisions without user input. I'll present 2-4 concrete options with trade-offs for you to choose."

Anti-Rationalization Table

Rationalization	Why It's WRONG	Required Action
"User seems busy, I'll skip the interview"	Skipping requirements gathering causes rework. 5 upfront questions < 3 implementation rewrites.	MUST complete interview for ambiguous requirements
"I can infer what they want from context"	Inference creates assumptions. Explicit confirmation prevents misunderstanding.	MUST get explicit answers, not infer intent
"Open-ended question will give richer response"	Open-ended questions are hard to answer and produce vague responses.	MUST provide 2-4 concrete options
"User said 'sounds good' - that's confirmation"	'Sounds good' is acknowledgment, not explicit confirmation.	MUST get explicit 'confirmed' or 'proceed'

Key Principles

Principle	Application
Explore before asking	30 seconds of exploration can save a question
Structured choices	Use AskUserQuestion with 2-4 concrete options
Show your work	Include what you found and why you're uncertain
Respect time	Max 3 rounds, max 4 questions per round
Confirm understanding	Always present summary for validation
Iterate if needed	Unclear confirmation = ask follow-up