Interactive Questions
Claude Code has a powerful feature: it can pause and ask you questions before proceeding. This leads to better outcomes on the first try.
The AskUserQuestion Tool
Section titled “The AskUserQuestion Tool”When Claude needs clarification, it can present you with structured questions and multiple-choice options:
Claude: Before I implement this feature, I have a few questions:
┌─────────────────────────────────────────────────────┐│ What authentication method should this API use? ││ ││ ○ JWT tokens (stateless, good for microservices) ││ ○ Session cookies (traditional, good for web) ││ ○ OAuth 2.0 (for third-party integration) ││ ○ Other (specify) │└─────────────────────────────────────────────────────┘Why This Matters
Section titled “Why This Matters”Traditional approach:
You: Add user authenticationClaude: [writes code with assumptions]You: No, I wanted JWT, not sessionsClaude: [rewrites code]You: Also needs refresh tokensClaude: [rewrites again]With interactive questions:
You: Add user authenticationClaude: [asks about JWT vs sessions, refresh tokens, etc.]You: [answer questions]Claude: [writes correct code first time]Triggering Questions
Section titled “Triggering Questions”Automatic (Plan Mode)
Section titled “Automatic (Plan Mode)”Plan mode naturally triggers questions. Press Alt+M to cycle to plan mode:
> add a notification systemClaude will ask:
- What types of notifications? (email, push, in-app)
- What events trigger notifications?
- Should users configure preferences?
- What’s the delivery mechanism?
Explicit Request
Section titled “Explicit Request”Ask Claude to interview you:
> I want to add a caching layer. Interview me to understand requirements before implementing.The Spec-Building Pattern
Section titled “The Spec-Building Pattern”A powerful workflow:
-
Start with a minimal prompt
> I need to add rate limiting to the API -
Ask Claude to interview you
> Before implementing, use the AskUserQuestion tool to clarify> all the requirements and edge cases -
Answer the questions
Claude presents structured options. You select or provide custom answers.
-
Review the spec
Claude summarizes what it understood. Confirm or correct.
-
Start a new session to implement
Terminal window # Copy the spec, start fresh> /clear> Implement this spec: [paste spec]
Question Types
Section titled “Question Types”Claude can ask different types of questions:
Single Choice
Section titled “Single Choice”┌─────────────────────────────────────────────────────┐│ Where should rate limit data be stored? ││ ││ ○ In-memory (resets on restart) ││ ○ Redis (persistent across instances) ││ ○ Database (with cleanup job) ││ ○ Other │└─────────────────────────────────────────────────────┘Multiple Choice
Section titled “Multiple Choice”┌─────────────────────────────────────────────────────┐│ Which endpoints need rate limiting? (select all) ││ ││ ☐ All endpoints ││ ☐ Authentication endpoints only ││ ☐ Data mutation endpoints (POST/PUT/DELETE) ││ ☐ Public API endpoints │└─────────────────────────────────────────────────────┘Open-Ended
Section titled “Open-Ended”┌─────────────────────────────────────────────────────┐│ What rate limit makes sense for your use case? ││ ││ Your answer: ____________________________ ││ ││ (e.g., "100 requests per minute per user") │└─────────────────────────────────────────────────────┘Best Practices
Section titled “Best Practices”1. Embrace the Interview
Section titled “1. Embrace the Interview”Don’t try to answer everything upfront. Let Claude draw out requirements:
# Instead of this> Add rate limiting, use Redis, 100 req/min, apply to auth> endpoints, return 429 with Retry-After header...
# Try this> Add rate limiting. Interview me about the requirements.2. Start Fresh After Planning
Section titled “2. Start Fresh After Planning”The interview fills context. Start a new session for implementation:
# After interview> /clear> Here's the spec from our discussion: [paste]> Implement this.3. Save Good Specs
Section titled “3. Save Good Specs”When Claude produces a good spec, save it:
# Save to a file> save this spec to docs/rate-limiting-spec.mdFuture Claude sessions can reference it:
> implement the spec in docs/rate-limiting-spec.mdExample: Full Interview Flow
Section titled “Example: Full Interview Flow”You: I want to add a user export feature
Claude: Great, let me understand the requirements.
┌─────────────────────────────────────────────────────┐│ 1. What data should be included in the export? ││ ││ ☐ User profile information ││ ☐ Activity history ││ ☐ Settings and preferences ││ ☐ Associated content (posts, comments) ││ ☐ Other │└─────────────────────────────────────────────────────┘
[You select: Profile, Activity, Settings]
┌─────────────────────────────────────────────────────┐│ 2. What format for the export? ││ ││ ○ JSON (developer-friendly) ││ ○ CSV (spreadsheet-friendly) ││ ○ ZIP with multiple files ││ ○ Other │└─────────────────────────────────────────────────────┘
[You select: ZIP with multiple files]
┌─────────────────────────────────────────────────────┐│ 3. How should the export be delivered? ││ ││ ○ Immediate download (small exports only) ││ ○ Email link when ready (async processing) ││ ○ Both options │└─────────────────────────────────────────────────────┘
[You select: Email link when ready]
Claude: Based on your answers, here's the spec:
## User Export Feature Spec
**Data included:**- User profile (name, email, created_at)- Activity history (login times, actions taken)- Settings (notification preferences, privacy settings)
**Format:** ZIP archive containing:- profile.json- activity.csv- settings.json
**Delivery:** Async processing with email notification- User clicks "Export Data"- Job queued in Celery- ZIP generated and stored in S3- Email sent with secure, time-limited download link
**Security:**- Rate limited: 1 export per 24 hours- Download link expires after 7 days- Requires re-authentication to download
Shall I proceed with implementation?