clarifylisted

# Clarify: Hypothesis-Based Requirement Clarification Use `$ARGUMENTS` to provide the ambiguous request to clarify. ## When This Skill Applies - User request triggers multiple conflicting intents (ambiguity score >= threshold) - Request is too broad to produce a meaningful plan - Critical dimensions are missing (target, scope, constraints, acceptance criteria) - User explicitly asks to clarify or refine a requirement - Cognitive router detects System 2 complexity but intent remains unclear ## The Three Ambiguity Types ### 1. Vague (Intent Unclear) The user has an idea but hasn't articulated what they want. | Signal | Example | |--------|---------| | Action verb missing | "the login page" | | Multiple possible actions | "do something about performance" | | Hedging language | "maybe we should look at..." | | Overly general | "improve the app" | **Strategy**: Present concrete hypothesis options derived from context. ### 2. Unknown (Information Missing) The user knows what they want but hasn't provided enough detail. | Signal | Example | |--------|---------| | Missing target | "add validation" (to what?) | | Missing constraints | "make it faster" (how fast? what metric?) | | Missing scope | "fix the bug" (which bug? which module?) | | Missing acceptance criteria | "it should work better" | **Strategy**: Ask for the specific missing dimension, one at a time. ### 3. Metamedium (Scope/Boundary Undefined) The user's request could be tiny or massive depending on interpretati