--- name: asking-questions description: 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. metadata: version: 1.0.7 --- # Asking Questions ## Purpose 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. ## When to Use Ask questions for: 1. **Ambiguous implementation choices** - Multiple valid technical approaches (middleware vs wrapper functions, library selection, architectural patterns) 2. **Missing critical context** - Specific information needed (database type, deployment platform, credential management) 3. **Potentially destructive actions** - Requests that could be interpreted dangerously ("clean up files" = delete vs archive) 4. **Scope clarification** - Vague terms like "refactor," "optimize," or "improve" 5. **Conflicting requirements** - Goals that may work against each other ("make it faster" + "add extensive logging") 6. **Technical trade-offs** - Solutions with different costs/benefits depending on priorities ## When NOT to Use Don't ask when: - **Request is clear and unambiguous** - One obvious implementation path - **You can determine the answer from context** - Codebase patterns, project structure, existing conventions - **Over-clarification** - Questions that don't materially affect implementation - **Standard engineering practices** - Established patterns already in the codebase ## Question Structure ### Template ``` [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] ``` ### Guidelines 1. **Acknowledge understanding first** - Show you've analyzed the situation - "I found your API endpoints and see you're using Express..." 2. **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 ``` 3. **Ask directly** - Clear question that guides decision - "Which approach fits your needs?" 4. **Offer autonomy (optional)** - For less critical decisions - "I can implement option 2 as it's the safest, or let me know if you prefer something else." ## Progressive Disclosure Layer questions instead of asking everything upfront: **Good ✓** - First: "For real-time updates, should I use WebSockets, Server-Sent Events, or polling?" - Then: "For WebSockets, do you want Socket.io (easier) or native (lighter)?" **Bad ✗** - "For real-time updates should I use WebSockets or SSE or polling and if WebSockets should I use Socket.io or native and should I implement reconnection and what about authentication and..." ## Examples ### Good ✓ "I see you're using JWT authentication. To add refresh tokens, I can: 1. **httpOnly cookies** - More secure, harder to XSS 2. **localStorage** - Simpler, works with mobile apps 3. **In-memory only** - Most secure, lost on refresh What works best for your use case?" ### Bad ✗ "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* --- ### Good ✓ "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)" ### Bad ✗ "What do you mean by clean up?" *Too vague, doesn't guide the decision* ## After Receiving an Answer 1. **Acknowledge** - Confirm you understood their choice 2. **Proceed immediately** - Don't ask if they want you to continue 3. **Apply preferences** - If they chose "security first" once, lean that direction for similar future choices ## Key Principle **Ask only when the answer materially changes what you'll build.** Avoid building the wrong thing, not asking questions for the sake of asking. --- Source attribution: oaustegard Original project: https://github.com/oaustegard/claude-skills/blob/2c9224e4bacd27e6f1094b3f4656e6ea4024dc06/asking-questions/SKILL.md License: MIT License information: https://opensource.org/license/mit Original upstream instructions; downloaded from Dave AI. ## Upstream license notice MIT License Copyright (c) 2025 Oskar Austegard Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. # Dave AI resource metadata Creator / publisher: oaustegard Original project: https://github.com/oaustegard/claude-skills/blob/2c9224e4bacd27e6f1094b3f4656e6ea4024dc06/asking-questions/SKILL.md Attribution basis: Recovered original package and original project license at a pinned revision Fields of work: Product Management, Sales Roles: Customer Success Manager, Product Manager, Sales Engineer, Sales Development Rep (SDR), Technical Product Manager Specialties: Cross Platform Tools: Tool not specified Country applicability: Country not specified Classification basis: Source catalog labels Instruction SHA-256: 6be138eeb6a9620a9f99cb17a0203ce96cd42eace395e45be27bb6d8e5de1442 Metadata reviewed: 2026-10-27 This metadata supersedes earlier Dave AI catalog attribution. Original instruction and supporting files are preserved.