# Clarify Request

> 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.).

- Skill: `prostdev/clarify-request` (Agent Skill)
- Install (CLI): `npx skillmds@latest add prostdev/clarify-request`
- Raw SKILL.md: https://api.skillmd.com/api/skills/prostdev/clarify-request/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: ProstDev (https://skillmd.com/u/prostdev)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/prostdev/clarify-request

---


# 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.