# Understanding The Ask

> Clarifies user intent before formalising requirements. Use when requests are vague, incomplete, or solution-focused, or when preparing to write a brief.

- Skill: `isvlasov/understanding-the-ask` (Agent Skill)
- Install (CLI): `npx skillmds@latest add isvlasov/understanding-the-ask`
- Raw SKILL.md: https://api.skillmd.com/api/skills/isvlasov/understanding-the-ask/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: isvlasov (https://skillmd.com/u/isvlasov)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/isvlasov/understanding-the-ask

---


# 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 fundamental goals or constraints (typically 3–5 exchanges): the user articulates a clear outcome, you understand the consequence of not solving it, and the need — not just the proposed solution — is clear.

### Step 3 — State your understanding

Reflect back at key moments — after exploring intent, before brief creation, when uncertain about something specific — not after every statement:

"Let me state back what I understand:
- **Problem:** [what's not working or missing]
- **Outcome:** [what success looks like]
- **Constraints:** [limitations, boundaries, must-haves]
- **Audience:** [who will use this]

Have I understood correctly? What have I missed?"

Iterate until the user confirms.

### Step 4 — Verify readiness

Ready to hand off when:

- [ ] The problem fits in one clear sentence
- [ ] The desired outcome is understood — not just the requested deliverable
- [ ] You know what success looks like and how the user will know it's solved
- [ ] You know why this matters now, who is affected, and who decides
- [ ] Scope boundaries are known (what's in, what's out)
- [ ] Understanding was stated back and confirmed; no contradictions remain

If not ready — concepts still unclear, the user keeps correcting you, significant aspects feel assumed — return to Step 2 and probe the unclear areas.

If ready, hand off to `creating-briefs`: the problem, desired outcome, audience, constraints, and success vision. Done well, it can formalise requirements without re-exploring intent.

## Common traps

- **Accepting ambiguous language** — "comprehensive", "good quality", "user-friendly" mean different things to different people. Probe: "Covering all edge cases, or just common scenarios?"
- **Mistaking symptoms for causes** — "the documentation is unclear" is a symptom; the cause may be missing examples, wrong audience level, or stale content. Keep probing.