Big tasks as chained steps

A procurement lead uploads forty supplier contracts and writes a single request: compare payment terms, penalties and renewal dates, recommend who to renegotiate with first, draft a memo for the CFO and an email to each chosen supplier. The answer arrives complete and polished. When she checks it, eleven suppliers are missing, two dates are wrong and the memo cites a penalty from another contract.

The problem is not that Claude can’t do each part. It is that a complex request mixes different tasks into a single answer, and the errors from the first part stay hidden under writing that looks finished.

Split and chain

Task decomposition means dividing the work into steps where each one does a single thing. The steps are chained: what comes out of one goes into the next. That is prompt chaining.

For the contracts case:

1. Extract. “Build a table with one row per contract: supplier, payment term, late-delivery penalty, renewal date. If a figure doesn’t appear, write ‘not stated’.”
2. Check. You (or someone on the team) check the table against a sample of contracts and confirm all forty are there.
3. Compare. “Using this table, rank the suppliers by renegotiation urgency and explain the criterion.”
4. Draft. The memo and the emails come out of the comparison that has already been checked.

Each intermediate output is something you can check in a few minutes. A forty-row table can be reviewed; a memo that blends forty contracts can’t.

Where to check

Step 2 is a checkpoint: the place where you look before building on top. It belongs after the step everything else depends on, which is almost always extracting or gathering data. An error in the table carries into the comparison, the memo and every email; fixed there, it is fixed once.

If review time is scarce (two experts with one session each, for example), spend it at the checkpoints, not on the final product.

Decomposing is not opening loose chats

Splitting without chaining brings another problem. A training specialist asked for a six-module course in a single request and it came out thin. So she opened six conversations, one per module, pasting the same short description. Each module gained depth, but they repeat each other, the same process has two different names and module five assumes something no module teaches.

She was missing a shared first step:

• An outline with objectives per module and a glossary, reviewed by her.
• Each module is drafted from that outline, which works as a common base.

That way the pieces fit from the start, instead of trying to stick them together at the end.

How it’s built	What happens
Everything in one request	Output that looks even, with hidden errors
Loose pieces with no common base	Each part fine, the whole incoherent
Chained steps with checks	Each step starts from data already checked

Common traps

• Rewriting the giant request with more emphasis (“check ALL the contracts”). It is still a single step.
• Asking Claude to review its own complete answer. It doesn’t replace a checkpoint against the source.
• Splitting into batches but asking for the final product in each batch. Four rounds of ten contracts, memo included, are four smaller giant requests.
• Splitting into separate chats with no shared outline or glossary.
• Leaving the review for the end, when the error is already everywhere.

On the exam

The scenario describes a task with several stages (gather, analyze, draft) done in one go, and a polished output with coverage or data errors. Look for the option that separates the extraction into a table or an outline, checks it and only then compares and drafts. If the scenario already shows loose pieces that don’t fit, the answer is a shared first step (outline, glossary, objectives) that all the others come from. Rule out the ones that only add emphasis, rely on self-review or leave the check for the final product.