Description: Crafting Clear Instructions for Claude
Once you have decided a task is worth delegating, the next question is how to tell Claude what you actually need.
That is Description, the second of the four practices in Anthropic Academy's AI Fluency Framework.
It is easy to underrate, because a bare instruction like "write a summary" will always produce something.
The problem is that something plausible is not the same as something useful, and the gap between the two is almost always a Description gap, not a limitation of Claude.
This page breaks down what a strong description actually contains and why each piece matters.
Summary
- Core Idea: Description is the practice of giving Claude enough context, explicit constraints, and a clear statement of the goal so it can act on your actual intent rather than guess at it.
- Why It Matters: A vague prompt forces Claude to fill gaps with assumptions, and those assumptions are frequently wrong in ways that only surface after the output is already written.
- Key Concepts: context, constraints, the actual goal, examples and templates, context-window awareness.
- When to Use: Every time you write a prompt, but especially for anything beyond a trivial, low-stakes request.
- Limitations / Trade-offs: More detail is not always better; over-specifying a simple task wastes time and can crowd out Claude's ability to make reasonable calls on genuinely minor details.
- Related Topics: Delegation judgment that precedes Description, context-window limits that shape how much detail fits, structured project briefs for larger tasks.
Foundations
A description has three components that matter more than any other.
The first is context: the background facts Claude needs but cannot know on its own, like who the audience is, what happened before this request, or what document this fits into.
The second is constraints: the explicit boundaries on the output, such as length, tone, format, what to include, and what to leave out.
The third is the actual goal: not just the task itself, but what the output needs to accomplish once it exists, which is often left unstated because it feels obvious to the person asking.
Consider the difference between "write a follow-up email" and "write a follow-up email to Priya, who asked for a revised quote after our call Tuesday; keep it under 150 words and end by proposing a call this week."
The second version supplies all three components in two sentences, and the resulting draft needs far less correction.
A simple way to think about it: a bare instruction tells Claude what to do, while a full description tells Claude what, for whom, within what limits, and toward what end.
The gap between those is where most disappointing first drafts come from.
Mechanics & Interactions
Description quality has a direct, mechanical effect on the practice that comes after it.
A vague prompt narrows nothing, so Claude has to choose among many plausible interpretations, and the one it picks may not match what you had in mind.
That mismatch does not usually look like an obvious error, it looks like a reasonable-sounding draft that quietly misses the point, which is exactly the kind of output that requires careful Discernment to catch.
A precise description narrows the space of plausible outputs before Claude ever starts writing, which means less has to be caught and corrected afterward.
This is why investing time in Description tends to save more time than it costs: a extra thirty seconds spent stating the audience and the goal can save several rounds of "not quite, try again."
Examples and templates are one of the highest-leverage additions to a description.
Showing Claude a previous version of a similar document, or a short sample of the tone you want, communicates format and voice far more precisely than describing them in words.
Weak: "Write a status update."
Better: "Write a status update. Use last week's update [attached]
as the template. Flag the API integration as 2 days behind;
root cause is a delayed sandbox on the vendor's side."This is also where context-window awareness becomes a practical Description skill rather than a technical detail: deciding what background is genuinely load-bearing for this specific request, versus what would just add noise, is part of writing a good description, not a separate concern.
Advanced Considerations & Applications
Description does not scale linearly with task complexity, it scales with ambiguity.
A complex but well-understood task, like "format these 50 rows into a table matching this example," needs very little prose description because the example itself carries most of the specification.
A simple-sounding but ambiguous task, like "make this sound better," needs much more description, because "better" could mean shorter, more formal, more persuasive, or a dozen other things, and Claude has no way to know which one you mean without being told.
This is why the skill of Description is really the skill of noticing where the ambiguity actually lives in a request, rather than adding detail everywhere uniformly.
Over-description has real costs.
Burying the one constraint that matters inside ten paragraphs of background makes it easy for that constraint to get lost, and demanding precise control over every minor stylistic choice can produce output that reads stiff or over-engineered rather than natural.
The skill is proportional specificity: be exact about what genuinely matters for this task, and leave Claude reasonable latitude on what does not.
| Description Style | Strength | Weakness | Best Fit |
|---|---|---|---|
| Bare instruction | Fast to write | High variance, frequent rework | Trivial, low-stakes, one-off requests |
| Context + constraints | Predictable, on-target output | Takes more upfront thought | Most real work tasks |
| Context + constraints + example/template | Highest fidelity to intended format and tone | Requires having a good example on hand | Recurring documents, matching an existing style |
| Structured brief (goal, constraints, background, success criteria) | Handles genuinely complex or ambiguous work | Overkill for small tasks | Multi-step projects, high-stakes deliverables |
For genuinely large or multi-part requests, a structured brief that separates goal, constraints, background, and success criteria into distinct sections outperforms a single dense paragraph, because it gives Claude, and a human reviewer, a clear checklist to work against.
Common Misconceptions
- "A longer prompt is always a better prompt." Length is not the goal; a short prompt that nails the audience and the actual goal beats a long one that buries the one constraint that mattered.
- "Claude should be able to infer the goal from the task alone." Claude can only work from what is stated; an unstated goal is not obvious to Claude the way it might be to a colleague who shares your context.
- "Examples are optional extras." An example or template is often the single most efficient way to communicate format and tone, more so than paragraphs of description.
- "Getting the description right is a one-shot skill." Most good descriptions are the product of one revision after seeing a first attempt fall short, not a perfect first try.
- "Description is just about writing better prompts." Description also includes deciding what context is worth including at all, which is a judgment call, not a writing exercise.
FAQs
What is Description in the AI Fluency Framework?
The practice of giving Claude sufficient context, explicit constraints, and a clear statement of the actual goal, so it can act on what you actually need rather than guess at it.
What are the three components of a strong description?
- Context: the background Claude cannot know on its own.
- Constraints: explicit limits like length, tone, and format, plus what to include or exclude.
- The actual goal: what the output needs to accomplish once it exists, not just the task itself.
Why does a bare instruction often produce a disappointing result?
Claude has to fill the gaps left by a vague request with assumptions, and those assumptions frequently miss what the person actually wanted, producing a plausible-looking draft that quietly misses the point.
How does Description quality affect the review step afterward?
A vague prompt widens the range of plausible outputs, so more has to be caught and corrected during review; a precise description narrows that range up front, which makes review faster and more reliable.
Why are examples or templates so effective in a description?
An example communicates format, tone, and structure more precisely than describing them in words, often saving an entire round of revision compared to a purely text-based instruction.
Can a description be too detailed?
Yes. Burying the one constraint that matters inside excessive background can make it easy to miss, and over-specifying every minor stylistic choice can produce stiff, over-engineered output; the goal is proportional specificity, not maximum length.
Does every task need the same amount of description?
No. Description scales with ambiguity, not complexity; a complex but well-understood task with a good example needs little prose, while a simple-sounding but ambiguous request needs more explanation of what you actually mean.
What is context-window awareness, and how does it relate to Description?
It is the judgment of what background information is genuinely load-bearing for a specific request versus what would just add noise; deciding that is a practical part of writing a good description, not a separate technical concern.
When should I use a structured brief instead of a single paragraph?
For genuinely large or multi-part requests, splitting goal, constraints, background, and success criteria into distinct sections gives both Claude and a human reviewer a clearer checklist than a single dense paragraph would.
What should I do if Claude's first draft misses the point?
Treat it as a signal about the description, not the tool; identify which of context, constraints, or goal was missing or unclear, and add exactly that in the next attempt.
Is writing a good description a one-time skill to learn?
It is closer to an ongoing habit: most strong descriptions are the result of one quick revision after seeing where a first attempt fell short, refined over repeated use rather than perfected on the first try.
How does Description relate to Delegation?
Delegation decides whether and how much to hand off; Description only matters once that decision is made, and a well-scoped delegation decision usually needs a shorter, simpler description than a high-stakes or ambiguous one.
Related
- The 4D AI Fluency Framework Explained - how Description fits with Delegation, Discernment, and Diligence.
- Delegation: Deciding What to Hand Off to Claude - the decision that comes before writing a description.
- Context Windows and Why Description Quality Matters - a deeper look at what to include versus leave out.
- Writing a Project Brief Claude Can Act On - turning Description into a structured brief for larger tasks.
Stack versions: Written against the Claude model lineup current as of ~June 2026 - Claude Fable 5, Claude Opus 4.8, Claude Sonnet 5 (the default), and Claude Haiku 4.5. Model names, pricing, and product features move quickly - verify current specifics at platform.claude.com/docs before relying on them.