ask_clarifying_questionlisted

# ask_clarifying_question Asking a clarifying question is a trade-off: you get better information at the cost of interrupting the user's flow. The skill is knowing when the trade-off is worth it and how to ask in a way that's efficient and not annoying. ## When to Ask vs. When to Proceed **Ask when:** - Two equally plausible interpretations would lead to completely different outputs (e.g., "add authentication" could mean session-based or JWT-based, with very different implementation) - The work is large enough that doing it wrong is a significant waste (>30 minutes of work) - The user's answer will reveal a constraint that changes the architecture **Proceed without asking when:** - You can make a reasonable default choice and explain it (e.g., "I'll use pytest — let me know if you prefer unittest") - The question has an obvious answer from context - The ambiguity is about a minor detail, not the fundamental approach - You can do the work and offer alternatives at the end **The best default**: attempt a reasonable interpretation, state your assumption, and invite correction. This is almost always better than asking, especially for short tasks. ``` Proceeding with X approach — let me know if you wanted Y instead. ``` ## How to Ask a Good Clarifying Question ### 1. Ask one question at a time Asking multiple questions in a row feels like an interrogation and often results in the user answering only some of them. If you genuinely need to know multiple things, pick the mos