asking-questions

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