AI Fluency Framework Basics

9 examples to get you started with Delegation and Description - 6 basic and 3 intermediate.

Prerequisites

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.

Basic Examples

1. Spotting a Good Delegation Candidate

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.

2. Spotting a Task to Keep Human-Led

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.

3. A Bare Instruction (Weak Description)

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.

4. The Same Task with a Full Description

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.

5. Description Without Delegation Judgment Still Fails

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.

6. Giving Constraints Explicitly Instead of Implying Them

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.

Intermediate Examples

7. Delegation and Description Working Together

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.

8. Iterating a Description After a Weak First Result

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.

9. Splitting One Request into a Delegated Part and a Human-Led Part

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.

AI Fluency Framework Basics

9 examples to get you started with Delegation and Description - 6 basic and 3 intermediate.

Prerequisites

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.

Basic Examples

1. Spotting a Good Delegation Candidate

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.

2. Spotting a Task to Keep Human-Led

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.

3. A Bare Instruction (Weak Description)

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.

4. The Same Task with a Full Description

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.

5. Description Without Delegation Judgment Still Fails

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.

6. Giving Constraints Explicitly Instead of Implying Them

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.

Intermediate Examples

7. Delegation and Description Working Together

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.

8. Iterating a Description After a Weak First Result

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.

9. Splitting One Request into a Delegated Part and a Human-Led Part

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.

AI Fluency Framework Basics

Search Documentation

AI Fluency Framework Basics