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