Prompting and Task Execution · Lesson 5 of 5

1.5 — Task Decomposition for Complex Requests

Break a large, multi-part request into an ordered sequence of smaller steps so Claude handles each part reliably instead of dropping or blending pieces.

A single prompt asking Claude to do five different things at once — "analyze this data, summarize the trends, draft an email about it, suggest three follow-up actions, and format it as a report" — often produces an output that does all five things shallowly, or quietly drops one. Task decomposition means breaking a complex request into an explicit, ordered sequence of smaller sub-tasks, either as separate prompts/messages, or as clearly numbered steps within one prompt that Claude is asked to work through in order.

When to Decompose vs. When One Prompt Is Fine

Not every multi-part request needs decomposition. A request with two closely related parts ("summarize this and suggest a title") is usually fine as one prompt. The signal that decomposition helps is when sub-tasks are sequentially dependent (step 2 needs step 1's actual output, not just the original input) or when a request genuinely spans different kinds of work (analysis, then drafting, then formatting) where doing them all at once tends to shortchange at least one.

Two Ways to Decompose

You can decompose within a single prompt, by numbering the steps explicitly and asking Claude to complete each in order before moving to the next ("First, list the three biggest trends in this data. Second, for each trend, write one sentence on its likely cause. Third, turn these into a two-paragraph summary."). Or you can decompose across messages, sending the data for analysis first, reviewing that output, then asking for the summary based on the reviewed analysis, then asking for the email draft. Across-message decomposition is slower but lets you catch a wrong turn early, before it propagates into every later step — worth the extra time for anything where an early mistake would be expensive to unwind.

Key Concept

Break a complex, multi-part request into an explicit ordered sequence — either numbered steps within one prompt, or separate messages — especially when later steps depend on the actual output of earlier ones, or when the request spans genuinely different kinds of work.

Common Exam Distractor

Don't assume decomposition always means splitting into multiple separate messages — numbered steps inside a single well-structured prompt are a valid form of decomposition too, and are often the more efficient choice when steps don't need independent review.

Exam traps

Treating any multi-part request as needing full decomposition into separate messages

Closely related, non-dependent sub-tasks are often fine in one prompt; decomposition is most valuable when steps are sequentially dependent or span different kinds of work.
Decomposing but not actually ordering the steps (listing five tasks with no sequence)

An unordered list of sub-tasks doesn't solve the dependency problem — the value of decomposition comes from an explicit order, especially when later steps rely on earlier output.

Practice question

A user asks Claude, in one message, to analyze a dataset, summarize the key trends, draft a stakeholder email about them, and suggest three follow-up actions. The response ends up doing all four things shallowly, and the email doesn't actually reference the specific trends found in the analysis. What would most directly fix this?

A Break the request into an ordered sequence — first get the analysis and trends, review that output, then ask for the email and follow-ups based on it Correct
The email needing to reference the actual trends found is a sequential dependency — decomposing into ordered steps, with the later steps built on the earlier output, directly fixes this.
B Ask for all four outputs again in the same single message, but in a different order
Reordering the same single-message request doesn't address the underlying dependency problem — the email still isn't grounded in a completed analysis.
C Add a role statement describing Claude as a senior data analyst
A role statement helps with tone and perspective, not with the structural problem of sequentially dependent sub-tasks being requested all at once.
D Shorten the request to ask for only the email, dropping the other three items
This avoids the problem rather than solving it — the user still needs the analysis, trends, and follow-ups; decomposition, not scope-cutting, is the fix.

Build exercise: Decompose a Multi-Part Request

Beginner · 20 minutes

You'll practice:

Recognise when a request has sequentially dependent sub-tasks
Practice both in-prompt and across-message decomposition
Compare output quality with and without decomposition

In claude.ai, paste in a small dataset or table (even a short list of numbers with labels) and, in one message, ask Claude to analyze it, summarize the trends, draft a two-sentence stakeholder update, and suggest one follow-up action.

This establishes a baseline showing the shallow-or-dropped-piece failure mode of an undecomposed, multi-part request.

You should see: A response where at least one part feels thin, generic, or doesn't clearly build on the others — e.g. the stakeholder update doesn't cite a specific number from the analysis.
Hints
1. ```
Use a dataset small enough that you can eyeball whether the analysis is actually correct.
```
2. ```
Check specifically whether the stakeholder update references a real figure or trend from the analysis, or just gestures vaguely at it.
```
3. ```
If the first attempt looks fine, add a fifth sub-task to increase the load.
```
Start a new conversation. Ask for the analysis and trends first, review the output, then send a second message asking for the stakeholder update and follow-up action based specifically on the trends just identified.

This applies across-message decomposition and lets you directly compare grounded, sequential output against the single-shot version.

You should see: A stakeholder update that explicitly references the actual trend or number from the first message's analysis.
Hints
1. ```
Read the analysis output before sending the second message — that's the point of decomposing across messages, catching problems early.
```
2. ```
In the second message, explicitly say 'based on the trends above' to reinforce the dependency.
```
3. ```
Compare both stakeholder updates side by side for specificity and grounding.
```

Sources

Written fresh — no CCAR-F equivalent
Anthropic docs — Prompt Engineering Overview