- No setup required beyond an active Claude.ai account (Free, Pro, or a team/enterprise seat).
- Read The 4D AI Fluency Framework Explained first if you have not seen the four practices before; this page assumes you know the names Delegation, Description, Discernment, and Diligence and focuses on the first two in practice.
- Every example below shows a realistic prompt or conversation moment, not code.
Recognize a task that is safe and useful to hand to Claude.
"Summarize these 12 customer support tickets into three themes, with one representative quote for each."
- This is repetitive synthesis work: reading many similar items and pulling out patterns.
- There is no irreversible action attached; a wrong summary is easy to catch and redo.
- The final decision, what to do about the themes, still belongs to the person reading the summary.
- Good delegation candidates share this shape: bounded input, low stakes if imperfect, and a clear human checkpoint afterward.
Recognize a task that should not be handed off wholesale, even though Claude could produce something.
"Should we let this employee go?"
- This is a final judgment call with real consequences for a person, not a drafting or research task.
- Claude was not present for the context, relationships, and history that should inform this decision.
- Accountability for the outcome cannot be delegated, so the decision itself should not be either.
- Claude can still help here in a narrower role, such as organizing documented performance history, without making the call itself.
See what happens when a request skips context and constraints.
"Write a follow-up email to the client."
- Claude has to guess the tone, the length, what happened in the prior conversation, and what outcome the email is for.
- The result will look like a plausible email, but it may not match the actual relationship or situation.
- Nothing here is wrong exactly, it is just underspecified, which pushes the guessing work onto Claude instead of the person who has the context.
- This is the shape to notice and improve, not a mistake to feel bad about; most first drafts of a prompt look like this.
Add context, constraints, and the actual goal to the same request.
"Write a follow-up email to Priya at Ashgrove Clinic. She asked for a revised quote after our call last Tuesday; the new quote is attached separately. Keep it under 150 words, friendly but professional, and end by proposing a call this week to walk through the numbers."
- The context (who, what happened, what is attached) removes the guesswork from step 3.
- The constraint (under 150 words, tone) narrows the range of acceptable drafts.
- The goal (propose a call) tells Claude what the email needs to accomplish, not just what it needs to say.
- Compare this to example 3: same task, but far less back-and-forth needed to get a usable draft.
Notice that a well-written prompt does not fix a bad delegation choice.
"Here is our full incident postmortem. Based on this, tell me whether we should terminate the vendor contract, and draft the termination notice."
- Even with excellent context in the prompt, this bundles a first-pass draft (fine to delegate) with a final contractual decision (not fine to delegate wholesale).
- A better split: ask Claude to summarize the postmortem's contract-relevant findings, then make the termination decision yourself, then delegate the notice drafting once the decision is made.
- This shows why Delegation and Description are separate skills: good instructions cannot rescue a task that should not have been handed off in that form.
Practice stating limits directly rather than hoping Claude infers them.
"Summarize this 40-page vendor contract. Only flag clauses related to data retention, liability caps, and termination rights. Ignore pricing and SLA sections, those are being reviewed separately. Output as a short bulleted list, not prose."
- Scope ("only flag," "ignore") prevents Claude from summarizing everything when you only need three areas.
- Format ("bulleted list, not prose") saves a round of "can you reformat this."
- Explicit exclusions are as useful as explicit inclusions; telling Claude what not to cover is part of Description.
- This kind of scoping matters more as documents get longer, since there is more for Claude to guess about without it.
See the two practices applied in sequence on a real task.
Step 1 (Delegation): decide that drafting a first-pass project status update is a good candidate to hand off, since the final review and send decision will stay with you.
Step 2 (Description): "Draft this week's status update for the Acme onboarding project. Use last week's update below as a template for tone and section headers. Flag the API integration as at risk, two days behind, root cause is a delayed sandbox from Acme's side. Keep the summary section to 3 sentences."
- The Delegation step happens first, mentally, before a single word is prompted.
- The Description step then supplies exactly what changed this week (the at-risk item) and a structural anchor (last week's update as a template).
- Providing a template or example is one of the highest-leverage additions to a description, since it removes ambiguity about format and tone in one move.
- The person still reviews and sends the update; delegation covered the draft, not the accountability for what gets sent.
Treat a disappointing output as a signal to improve the description, not just the output.
First attempt: "Write talking points for our board meeting about Q3 results."
Result: generic, doesn't mention the specific numbers or the one contentious topic (a missed revenue target).
Revised: "Write 5 talking points for our board meeting about Q3 results. We hit 92% of the revenue target, driven mainly by slower enterprise deal cycles; the board will ask about this directly, so one talking point must address it head-on with our Q4 plan to close the gap. Audience is 6 board members, all familiar with the business, so skip background explanation."
- The first attempt failed because it lacked the one piece of information (the missed target) that actually mattered to the audience.
- Naming the audience ("6 board members, all familiar with the business") let Claude skip explanatory filler that would have wasted the board's time.
- This is the loop in practice: a weak result is diagnosed as a Description gap, not treated as "Claude got it wrong," and the next prompt fixes that specific gap.
- Iterating on the description is usually faster than trying to fix the output by hand.
Break a mixed request into the piece worth delegating and the piece that is not.
Original ask: "Handle the layoff announcement for the design team."
Split:
- Human-led: decide who is affected, the timeline, and the severance terms; decide the key message and tone with HR and legal.
- Delegated: "Given these decided facts [list], draft the internal announcement email and a short FAQ for managers to use in 1:1s. Keep the tone direct and compassionate, avoid corporate euphemism, and keep the FAQ to 6 questions."
- Splitting the task makes the delegation boundary explicit instead of leaving it implicit and easy to blur.
- All of the sensitive, accountability-heavy decisions happen before Claude is involved at all.
- The delegated part is now well-scoped drafting work with clear constraints, which is exactly the shape of a good Delegation candidate from example 1.
- This pattern, decide first, then delegate the drafting of the decided outcome, generalizes to most high-stakes communications.
Related: Delegation: Deciding What to Hand Off to Claude - deeper criteria for the first D | Description: Crafting Clear Instructions for Claude - deeper technique for the second D | Delegation Decision Checklist for Everyday Tasks - a quick checklist version of example 1 and 2
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.