Understanding the Ask

Purpose

This skill guides you through structured dialogue with users to understand what they actually want before formalising requirements into briefs.

Users arrive with vague requests, incomplete specifications, or solution-focused language. Your role is to systematically explore intent, context, and constraints through structured questioning and reflective listening, producing sufficient clarity to hand off to the creating-briefs skill.

This skill operates at the start of the Preparation phase, before brief creation begins.

When to Use

Use this skill when:

• User's request is vague or incomplete ("make it better", "improve the docs")
• User proposes a specific solution without explaining the underlying problem
• Context or purpose is unclear (why this, why now)
• Success criteria are unstated or ambiguous
• Multiple interpretations of the request are possible

Skip this skill when:

• Request is already clear and specific with stated outcomes
• User has provided comprehensive brief or requirements
• Task is trivial with obvious intent (simple file edit, straightforward clarification)

Core Principles

Distinguish needs from proposed solutions — Users often state solutions, not problems; your job is discovering the underlying need.

Create verification checkpoints — State your understanding back to the user periodically; don't assume you've understood correctly.

Stay in problem space before solution space — Explore what problem exists and why it matters before discussing implementation approaches.

Context is never obvious — Don't assume you know why the user wants this, who will use it, or where it fits.

Workflow

Step 1: Capture the Initial Statement

What you're doing: Understanding the surface-level request and establishing basic context.

Questions to ask:

• "What are you looking to create/achieve?" (the what)
• "Who will use this?" (the audience)
• "Where does this fit in your current work?" (the context)

At this stage: You're capturing what they think they need, not yet probing why. Keep questions open-ended starting with "what" or "how" rather than "why" (which can feel defensive).

Output: Basic understanding of the request, audience, and immediate context.

Step 2: Explore Intent and Motivation

What you're doing: Understanding the underlying need and purpose behind the request.

Depth questioning technique:

Don't literally ask "why" five times. Instead, use gentle framing that invites elaboration:

• "What's driving this need right now?"
• "What would having this enable you to do?"
• "Help me understand what problem this solves"
• "What happens if we don't address this?"

When users propose specific solutions, probe for the outcome:

• User says "I need a comprehensive API reference" → "What would having that reference enable your team to do?"
• User says "Create a new skill for X" → "What gap are you experiencing that this skill would fill?"

Watch for premature solutioning:

These signals indicate jumping to solutions before problem context is clear:

• Discussion of specific tools or technologies before problem is defined
• Fixation on a deliverable type without discussing what it must achieve
• "We need to implement X" without corresponding "because Y" context
• Talk of features before outcomes

Corrective questions:

• "Before we discuss how to do that, can we clarify what problem that solves?"
• "What outcome does this implementation need to achieve?"
• "I notice we're discussing specifics. Can we step back to the problem space?"

Balance: Sometimes stating a preliminary interpretation helps users clarify. Don't avoid all solution discussion—just ensure problem context exists first.

Depth signals:

Stop when you reach fundamental goals or constraints (typically 3-5 exchanges). You've gone deep enough when:

• User articulates a clear outcome or success state
• You understand the consequence of not solving this
• The underlying need is clear, not just the proposed solution

Output: Understanding of why this matters, what problem it solves, what outcome the user wants.

Step 3: State Your Understanding

What you're doing: Creating a verification checkpoint by reflecting back what you've heard.

Reflective listening templates:

Use these phrase patterns to state understanding:

• "What I'm hearing is..."
• "My understanding: you need [X] because [underlying goal/constraint]..."

Structure for comprehensive reflection:

"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?"

Frequency: Don't reflect after every statement. Use this at key moments—after exploring intent (Step 2), before moving to brief creation (Step 4), when you're uncertain about something specific.

Output: User confirms your understanding or corrects misinterpretations. Iterate until alignment achieved.

Step 4: Verify Readiness to Proceed

What you're doing: Checking whether you have sufficient understanding to create a brief.

Readiness checklist:

You're ready to proceed when:

• [ ] You can state the problem in one clear sentence
• [ ] You understand the desired outcome (not just requested deliverable)
• [ ] You know what success looks like
• [ ] You understand why this matters now (urgency/context)
• [ ] You've identified who is affected and who decides
• [ ] You've stated understanding back and user confirmed
• [ ] No major ambiguities or confusion remain
• [ ] You understand boundaries (what's in/out of scope)

5W+H coverage check:

Have you covered:

• Who: Who is affected? Who needs this?
• What: What is the problem? What would success look like?
• When: When does this need to happen?
• Where: Where does this fit in their work?
• Why: Why does this matter? Why now?
• How: How will they know when it's solved?

When NOT ready:

• Core concepts still unclear or confusing
• User keeps correcting your understanding
• Significant aspects feel vague or assumed
• Haven't verified understanding back with user
• Contradictory information hasn't been resolved

If not ready: Return to Step 2. Probe deeper on unclear areas. State understanding again.

If ready: Proceed to creating-briefs skill to formalise requirements.

Output: Confirmed readiness or identification of gaps requiring further exploration.

Common Traps to Avoid

Accepting ambiguous language — Terms like "comprehensive", "good quality", "user-friendly" mean different things to different people. Probe: "When you say comprehensive, do you mean covering all edge cases or just common scenarios?"

Focusing on symptoms not causes — User says "the documentation is unclear". That's a symptom. The cause might be missing examples, wrong audience level, or outdated content. Use depth questioning to go deeper.

Handoff to Creating-Briefs

When readiness criteria are met, you have what creating-briefs needs to begin.

What you're handing off:

• Clear understanding of the problem and desired outcome
• Context for why this matters and where it fits
• Audience identification
• Boundaries and constraints
• Success vision (what good looks like)

What creating-briefs does next:

• Extracts requirements from applicable standards
• Formalises success criteria as measurable checkboxes
• Structures requirements into brief format
• Establishes quality expectations

Clean handoff means: You've done the exploration work so creating-briefs can move directly to formalisation without re-exploring intent.

Evaluation Scenarios

Scenario 1: Vague Request to Clear Understanding

User says: "I need better documentation for the deployment process"

Expected outcome:

• Explore: What problem does current documentation create? Who uses it? What would "better" mean?
• Probe outcomes: "What would good deployment docs enable your team to do?"
• Detect premature solutioning if user jumps to format discussions before problem is clear
• State understanding: "It sounds like new team members take 3 weeks to contribute because deployment docs are outdated, and you need docs that enable independent deployment in under a week. Is that right?"
• Verify readiness: Problem clear, outcome measurable, audience identified, constraints understood
• Hand off to creating-briefs with: problem (new hires can't deploy independently), outcome (deploy without help in 1 week), audience (new engineers), constraints (staging and production, not admin endpoints)

Scenario 2: Solution-Focused Request

User says: "Create a new skill using the Jobs-to-be-Done framework"

Expected outcome:

• Recognise premature solutioning (jumped to solution before stating problem)
• Probe: "What gap are you experiencing that this skill would fill? What would having this skill enable you to do?"
• Explore context: "Why Jobs-to-be-Done specifically? What problem does it solve that other frameworks don't?"
• State understanding: "What I'm hearing is that orchestrators sometimes guess user intent rather than probing deeply, and Jobs-to-be-Done provides a framework for discovering underlying needs. You want a skill that teaches this technique. Is that right?"
• Verify outcome: "How will you know if this skill succeeds?"
• Hand off to creating-briefs with: problem (orchestrators guess intent), outcome (systematic intent discovery), audience (orchestrators), framework constraint (must include JTBD), success criteria (orchestrators can distinguish needs from proposed solutions)

Scenario 3: Incomplete Request

User says: "Research progressive disclosure patterns"

Expected outcome:

• Establish context: "Why are you interested in progressive disclosure? What problem are you trying to solve?"
• Probe scope: "Progressive disclosure for what type of content? Which aspects matter most?"
• Explore usage: "How will you use these research findings? Who needs to understand them?"
• Check boundaries: "Should this cover interactive patterns, or just static documentation approaches?"
• State understanding: "My understanding: your skills are growing long (400+ lines), creating discoverability problems. You need proven patterns for splitting content while maintaining usability. This research will identify 3-5 patterns for your skill structure. Is that right?"
• Verify readiness: Problem clear (discoverability), outcome defined (3-5 patterns), usage specified (inform skill structure), scope bounded (CLI tools, progressive disclosure focus)
• Hand off to creating-briefs with: problem (long skills, discoverability), outcome (identify 3-5 patterns), audience (orchestrator will decide structure), scope (CLI tools, progressive disclosure focus)

Success Indicators

This skill succeeds when:

• You move from vague request to clear understanding efficiently
• User confirms "yes, you've understood what I need" when you reflect back
• Creating-briefs can proceed without re-exploring intent
• Briefs capture actual need, not literal surface request
• Orchestrator can articulate the problem, outcome, and constraints in a way the user confirms as accurate