Vague Request to Clear Brief
Category analysis
Subcategory task-clarification
Difficulty beginner
Target models: claude-sonnet, gpt, gemini-pro
Variables:
{{raw_request}} {{target_outcome}} {{audience_or_stakeholders}} {{known_constraints}} {{workflow_surface}} prompting clarity briefing task-definition requirements
Updated April 23, 2026
The Prompt
You are a task-clarification coach. Turn the vague request below into a clearer brief that a human or AI assistant can actually execute.
RAW REQUEST:
{{raw_request}}
TARGET OUTCOME:
{{target_outcome}}
AUDIENCE OR STAKEHOLDERS:
{{audience_or_stakeholders}}
KNOWN CONSTRAINTS:
{{known_constraints}}
WORKFLOW SURFACE:
{{workflow_surface}}
Return exactly:
1) Interpreted goal (one sentence)
2) What is still unclear (bullet list)
3) Clarifying questions (max 7, only the highest-value questions)
4) Draft brief with:
- goal
- context
- constraints
- desired output shape
5) Assumptions that should be confirmed before execution
6) Suggested next prompt to use after the brief is approved
Rules:
- Do not pretend the original request is clearer than it is.
- Separate confirmed facts from assumptions.
- If the request bundles multiple tasks, split them explicitly.
- Prefer plain language over prompt-jargon.
- If the target outcome is still fuzzy, propose 2-3 realistic output shapes instead of guessing one silently.
When to Use
Use this when the first request is real but under-specified. It is useful for solo work, team handoffs, and AI-assisted workflows where the output quality depends more on the brief than on the model.
Good scenarios:
- a stakeholder says “make this better”
- you know the direction but not the actual deliverable
- a coding, writing, or research task feels bundled and messy
- you want a stronger brief before handing the work to another person or tool
Variables
| Variable | Description | Good input examples |
|---|---|---|
raw_request | The vague or messy request as originally stated | ”Help with our launch update”, “Fix this AI page”, “Make this analysis more useful” |
target_outcome | What success should produce if known | ”Sendable team update”, “reviewable implementation plan”, “clear executive summary” |
audience_or_stakeholders | Who the result is for or who must approve it | product lead, founder, engineering team, customers |
known_constraints | Time, format, risk, or scope limits | ”under 300 words”, “no schema changes”, “must use existing notes only” |
workflow_surface | Where the clarified brief will be used next | chat app, coding agent, editor workflow, analyst handoff |
Tips & Variations
- If you do not know the target outcome yet, say so and let the model propose 2-3 likely output shapes.
- For team use, paste the raw ticket or Slack message exactly as written so the clarification is grounded in the real ask.
- Add “mark any risky assumption as HIGH_RISK” when approval quality matters.
- Use this before deeper prompts like refactor plans, creative briefs, or stakeholder updates.
- If the brief will be handed to an agent or automation system next, ask for a draft that separates read-only context from action permissions.
Example Output
Interpreted goal: Turn loose launch notes into a short update that clarifies progress, risks, and decisions for leadership.
What is still unclear: which audience is primary, whether dates are confirmed, and whether unresolved risks should be named explicitly.
Suggested next prompt: “Write a leadership update from this approved brief using exactly four sections and no invented commitments.”