Guidance for asking clarifying questions when user requests are ambiguous, have multiple valid approaches, or require critical decisions. Use when implementation choices exist that could significantly affect outcomes.
Ask clarifying questions when the answer materially changes what you'll build. This skill helps identify when to ask, how to structure questions effectively, and when to proceed autonomously.
Ask questions for:
Don't ask when:
[Context: What you found/analyzed]
[Present 2-5 specific options with brief trade-offs]
[Direct question asking for preference]
[Optional: Offer to make reasonable default choice]
Acknowledge understanding first - Show you've analyzed the situation
Present clear options - Offer 2-5 specific choices with brief context
I can implement this in several ways:
1. **Global middleware** - Catches all errors centrally (simplest)
2. **Wrapper functions** - More granular control per endpoint
3. **Custom error classes** - Typed errors with status codes
Ask directly - Clear question that guides decision
Offer autonomy (optional) - For less critical decisions
Layer questions instead of asking everything upfront:
Good ✓
Bad ✗
"I see you're using JWT authentication. To add refresh tokens, I can:
What works best for your use case?"
"How should I implement the authentication refresh token storage mechanism considering security implications, XSS vulnerabilities, mobile compatibility, UX impacts, and compliance considerations?"
Too verbose, no clear options, asks everything at once
"You mentioned 'clean up migrations.' Do you want me to archive them to /old-migrations or delete them entirely? (Note: deletion can break databases that haven't run them yet)"
"What do you mean by clean up?"
Too vague, doesn't guide the decision
Ask only when the answer materially changes what you'll build. Avoid building the wrong thing, not asking questions for the sake of asking.