Clarify the Request
Most requests arrive underspecified. When there are several plausible ways to read one,
a few sharp questions up front beat producing a confident wrong answer. Clarify first,
then act.
When to use — and when not to
- Use when the outcome, audience, scope, or format is unclear; when the request has
multiple reasonable interpretations; or when the user signals they aren't sure what they
want or asks you to help figure it out.
- Skip or go light when the request is already specific and unambiguous. Right-size to
the ambiguity — don't interrogate a clear ask. The goal is a shared understanding, not a
quota of questions.
First, discover — don't ask what you can find
If a fact is knowable from the environment (files, tools, prior messages, the web), look
it up rather than asking. Reserve questions for what only the user can answer: their goal,
taste, constraints, and priorities.
What to clarify (pick the few that matter most)
Adapt this checklist to the domain — a blog post, a design, a contract, and a parenting
question each lean on different rows:
- Outcome — what does a great result look like, and what will they do with it?
- Audience — who is this for, and what do they already know?
- Scope — what's explicitly in vs. out? How deep, how long, how many?
- Format — the shape of the deliverable (prose, list, doc, code, design, plan…).
- Constraints — must-haves, must-nots, tone/style, deadline, budget, brand/legal rules.
- Context — background you lack, prior attempts, and examples they like or dislike.
- Success criteria — how will they judge whether it's good?
How to ask
- Lead with the highest-leverage unknowns — the answers that most change what you produce.
- Keep the first round small (roughly 3–5 questions). A wall of questions is bewildering.
- For each question, offer your recommended default so the user can accept with one word.
- Prefer concrete options over open-ended when you can ("A, B, or C?" beats "what tone?").
- Ask, then let the answers reshape what you ask next. Resolve dependencies as you go.
Close the loop
- Once you have enough, play back a short brief (2–4 lines): goal, audience, scope, format,
key constraints — so any wrong assumption surfaces before you invest in it.
- Get a confirmation (or corrections) before producing the deliverable.
- Stop as soon as the path is clear. Over-clarifying wastes the user's time as surely as
guessing wastes yours.
1---2name: clarify-request3description: Turn a vague or underspecified request into a clear, actionable brief by asking a few targeted questions before acting. Use when a prompt is ambiguous, the user isn't sure exactly what they want, or asks you to help clarify/refine what they're asking — across any domain (writing, design, legal, planning, research, defining a skill, a personal problem, etc.).4---56# Clarify the Request78Most requests arrive underspecified. When there are several plausible ways to read one,9a few sharp questions up front beat producing a confident wrong answer. Clarify first,10then act.1112## When to use — and when not to1314- **Use** when the outcome, audience, scope, or format is unclear; when the request has15 multiple reasonable interpretations; or when the user signals they aren't sure what they16 want or asks you to help figure it out.17- **Skip or go light** when the request is already specific and unambiguous. Right-size to18 the ambiguity — don't interrogate a clear ask. The goal is a shared understanding, not a19 quota of questions.2021## First, discover — don't ask what you can find2223If a *fact* is knowable from the environment (files, tools, prior messages, the web), look24it up rather than asking. Reserve questions for what only the user can answer: their goal,25taste, constraints, and priorities.2627## What to clarify (pick the few that matter most)2829Adapt this checklist to the domain — a blog post, a design, a contract, and a parenting30question each lean on different rows:3132- **Outcome** — what does a great result look like, and what will they do with it?33- **Audience** — who is this for, and what do they already know?34- **Scope** — what's explicitly in vs. out? How deep, how long, how many?35- **Format** — the shape of the deliverable (prose, list, doc, code, design, plan…).36- **Constraints** — must-haves, must-nots, tone/style, deadline, budget, brand/legal rules.37- **Context** — background you lack, prior attempts, and examples they like or dislike.38- **Success criteria** — how will they judge whether it's good?3940## How to ask4142- Lead with the highest-leverage unknowns — the answers that most change what you produce.43- Keep the first round small (roughly 3–5 questions). A wall of questions is bewildering.44- For each question, offer your **recommended default** so the user can accept with one word.45- Prefer concrete options over open-ended when you can ("A, B, or C?" beats "what tone?").46- Ask, then let the answers reshape what you ask next. Resolve dependencies as you go.4748## Close the loop4950- Once you have enough, play back a short brief (2–4 lines): goal, audience, scope, format,51 key constraints — so any wrong assumption surfaces before you invest in it.52- Get a confirmation (or corrections) before producing the deliverable.53- Stop as soon as the path is clear. Over-clarifying wastes the user's time as surely as54 guessing wastes yours.
ProstDev