Delegation & Description Best Practices
Ten practical habits for delegating tasks and writing descriptions Claude can act on, grouped into three areas: judging what to delegate, writing the description itself, and closing the loop once you see the result.
How to Use This List
- Treat each habit as something to build, not a one-time rule to apply once and forget.
- The habits are ordered roughly in the sequence they come up: judgment first, then description, then follow-through.
- Revisit this list after a task did not go the way you expected; it usually points to which habit was skipped.
A - Delegation Judgment
- Decide what to delegate before you write a single word of the prompt. Making the delegation call first keeps you from backfilling a justification for handing off a task that should have stayed human-led.
- Split bundled requests at the seam between decision and drafting. Many real asks combine a judgment call with the writing or research that follows it; delegate the second part and keep the first.
- Treat repeated heavy correction as a signal about the delegation call, not just the prompt. If a supposedly safe task keeps coming back wrong, reconsider whether it belongs in the human-led or partial category instead.
- Match the delegation decision to today's stakes, not the task's usual stakes. The same type of task, like a public statement, can shift from safe to delegate to human-led depending on timing and audience.
B - Writing the Description
- State the actual goal, not just the task. "Draft a status update" is a task; "flag the at-risk item early enough that no one is surprised" is a goal, and the goal is what should shape the draft.
- Name the audience explicitly. Who will read or use the output changes what needs explaining and what can be assumed, and Claude has no way to know the audience unless you say so.
- Give constraints as concrete limits, not vague preferences. "Keep it fairly short" leaves room for guesswork; "under 150 words" does not.
- Include an example or template when format and tone matter. A short sample communicates voice and structure more precisely than a paragraph describing them.
C - Closing the Loop
- Read the output critically before relying on it, even when it reads well. Fluent, confident-sounding text can still be off-target or wrong; treat the first read as a review, not a rubber stamp.
- Diagnose a weak result as a specific gap, then fix only that gap. Identify whether context, a constraint, or the goal itself was missing, and revise that piece rather than rewriting the whole request from scratch.
FAQs
Why are these habits grouped into three areas instead of one flat list?
Because they happen in sequence during real use: a delegation judgment call comes first, a description follows once that call is made, and closing the loop happens after Claude responds; grouping them this way mirrors how the habits actually get used.
Which habit matters most if I can only focus on one?
Stating the actual goal, not just the task, tends to have the single biggest effect on output quality, since it is the piece most often left implicit in a bare request.
What should I do if I keep having to correct Claude's output on a task I've delegated before?
Treat it as a signal about the delegation decision itself, not only the prompt, and reconsider whether the task actually belongs in a human-led or partially delegated category.
Is splitting a bundled request always necessary?
Only when the request actually mixes a judgment call with drafting or research; a request that is purely one or the other does not need to be split.
Why does naming the audience matter so much?
Because the audience determines what needs explaining and what can be assumed as already known; without it stated, Claude has to guess, and that guess is often wrong for a specific reader.
What's the difference between a vague constraint and a concrete one?
A vague constraint like "keep it short" leaves the actual limit to guesswork; a concrete constraint like "under 150 words" gives Claude something specific to check the output against.
Why include an example instead of just describing the tone in words?
An example communicates format, structure, and voice more precisely and faster than a paragraph of description trying to capture the same thing in words.
Why does fluent-sounding output still need a critical read?
Because Claude's output is typically well-written and confident in tone regardless of whether the underlying content is fully correct, which makes an off-target or wrong answer easy to miss without deliberately reading for it.
What does it mean to "diagnose" a weak result rather than just redoing it?
It means identifying which specific piece, context, a constraint, or the stated goal, was actually missing or unclear, and fixing that piece directly instead of guessing broadly at a full rewrite.
Does the stakes-based delegation habit mean the same task type can be treated differently on different days?
Yes; a task type like drafting a public statement is not fixed as safe or risky, its stakes shift with context such as timing and audience, so the delegation call should be made per instance, not by category alone.
Do these ten habits replace reading the full Delegation and Description pages?
No, this list is a quick-reference summary; the full Delegation and Description pages explain the reasoning and edge cases behind each habit in more depth.
Related
- Delegation: Deciding What to Hand Off to Claude - the reasoning behind the Delegation Judgment habits.
- Description: Crafting Clear Instructions for Claude - the reasoning behind the Writing the Description habits.
- Delegation Decision Checklist for Everyday Tasks - a step-by-step checklist version of habit A.
- AI Fluency Framework Basics - worked examples showing these habits in daily conversations.
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.