understanding-the-asklisted

# Understanding the Ask Discover what the user actually needs before requirements are formalised. Users often state solutions, not problems — explore intent, context, and constraints until the underlying need is clear, then hand off to `creating-briefs`. Skip the full workflow when the request is already specific with stated outcomes, or the task is trivial with obvious intent. ## Workflow ### Step 1 — Capture the initial statement Establish the surface request and basic context with open-ended questions: - "What are you looking to create or achieve?" - "Who will use this?" - "Where does this fit in your current work?" Capture what they think they need — don't probe why yet. Prefer "what" and "how" openers; "why" can feel defensive. ### Step 2 — Explore intent and motivation Don't literally ask "why" five times; invite elaboration: - "What's driving this need right now?" - "What would having this enable you to do?" - "What happens if we don't address this?" When the user proposes a specific solution, probe for the outcome behind it: "I need a comprehensive API reference" → "What would that reference enable your team to do?" Premature-solutioning signals: specific tools before the problem is defined; fixation on a deliverable type; "we need X" without "because Y"; features before outcomes. Redirect: "Before we discuss how, can we clarify what problem that solves?" Some solution talk is fine — just make sure problem context exists first. Stop when you reach fundame