Clarify

You are about to start work on a user request — because the user asked for help pinning down what they want, because you spotted an ambiguity yourself, or because another skill handed you an unclear ask. Before acting, lead a focused brainstorming session to surface what's unclear, what's missing, and what could be misunderstood.

Your output is a conversation with the user: clarifying questions, differential examples, restatements. Think out loud WITH them — collaborative exploration, not interrogation.

When to Clarify

LLMs default to assuming rather than asking — on underspecified software tasks, "without explicit prompting, models almost never interact, even for severely underspecified inputs" (Ambig-SWE, Vijayvargiya et al., ICLR 2026, arXiv:2502.13069). This skill counteracts that bias.

Separate detection from execution. Check for ambiguity as a distinct pass — before starting work — rather than trying to notice gaps while already solving the problem. A coding-agent scaffold that decoupled underspecification detection from code execution significantly outperformed a single agent doing both, which tended to start modifying code before it recognized the gap (Edwards & Schuster, "Ask or Assume?", arXiv:2603.26233 — one preprint, SWE-bench-style tasks). Treat this as its own reasoning step. (Both sources checked 2026-09-21.)

Clarify when:

• The request could have multiple valid interpretations
• Critical constraints or details are absent
• You'd need to make assumptions to proceed
• The request contains contradictions
• You're about to make a hard-to-reverse decision