D2 · Decomposing Work into Steps

This domain is worth 18% of the mock — roughly 9 of 50 items and the second-heaviest section. It tests the single skill that most separates a competent prompter from someone who builds reliable workflows: taking a task that feels like one instruction and breaking it into named steps you can inspect, test and fix independently. The recurring villain here is the mega-prompt — one enormous instruction that tries to do everything at once and fails in ways you cannot diagnose.

What you need to know

Decomposition is the act of turning “do this whole thing” into a sequence of smaller steps, each with a clear job, so that quality, cost and failure are all visible. Four patterns cover almost every workflow: sequential (step B consumes step A’s output), fan-out/fan-in (split into parallel pieces, then combine), draft-then-critique (produce, then a separate pass reviews and revises), and extract-then-transform (pull structured data out, then act on the structure). The failure mode to recognise is the mega-prompt: it works on the demo, hides where it went wrong, and cannot be improved because you cannot see the seams. Good decomposition makes each step small enough to verify and cheap enough to run on the lightest capability that will do it.

Learning objectives

By the end of this page you should be able to:

Decompose a compound task into named steps with clear inputs and outputs.
Select the right decomposition pattern — sequential, fan-out/fan-in, draft-then-critique, extract-then-transform — for a given task.
Diagnose the mega-prompt failure mode and explain why a single step is failing opaquely.
Decide the right granularity: when to split a step further and when splitting adds pointless overhead.
Route each step to an appropriate capability and reviewer based on its job.

2.1 Why decompose at all

A single mega-prompt asks the model to hold many sub-goals in mind at once and produce one blended answer. Three things go wrong.

Problem with the mega-prompt	Consequence
Sub-goals compete for attention	The model does the easy ones well and drops or half-does the hard ones
Failure is opaque	When the output is wrong you cannot tell which sub-goal failed
Nothing is independently testable	You cannot fix one part without re-running and re-checking the whole thing
No place for review	A human gate has to sit before or after the whole blob, not at the risky step

Decomposition fixes all four: each step has one job (done well), a visible output (so you see where it broke), an independent test (so you fix it in isolation), and a natural place for a review point.

Assessment signal

Stems describing an output that is “sometimes right, sometimes drops a section”, “hard to debug”, or “works in the demo but not in production” are pointing at a mega-prompt. The right answer is almost always “break it into steps”, not “write a longer prompt” or “use a bigger model”.

2.2 The four decomposition patterns

Pattern	Use it when	Example
Sequential	Later work genuinely depends on earlier work	Outline → draft → tighten
Fan-out/fan-in	The work splits into independent pieces	Summarise 10 docs separately, then synthesise one brief
Draft-then-critique	Quality needs a fresh-eyes pass the drafting model won’t give itself	Draft a policy → separate critique pass against a checklist → revise
Extract-then-transform	You need reliable structure before acting	Pull fields from invoices → categorise the structured records

2.3 Sequential decomposition

The default. Each step’s output is the next step’s input, so a bad early step poisons everything downstream — which is exactly why splitting helps: you catch the bad outline before you draft 2,000 words on it.

Worked example — a client-ready proposal:

One shot, six sub-goals. The pricing and the timeline drift out of sync; the exec summary summarises a version that no longer exists; you cannot tell which part is wrong without re-reading everything.

Each step is inspectable; the exec summary is written last so it matches; the pricing check happens where the numbers are produced.

2.4 Fan-out / fan-in

When pieces are independent, do them separately and combine. This raises quality (each piece gets full attention) and lets you parallelise, but the fan-in step is where consistency is enforced.

Example. Summarise twelve regional sales reports into one national brief.

Fan-out: summarise each report to a fixed mini-template (region, revenue, top risk, one highlight).
Fan-in: synthesise the twelve mini-summaries into the national brief; reconcile terminology and totals here.

The trap is skipping the fan-in discipline: twelve summaries stapled together is not a brief. The fan-in step must reconcile (dedupe, total, resolve contradictions), not just concatenate.

Assessment signal

“Ten independent documents”, “several branches”, “combine the results” point to fan-out/fan-in. If the stem stresses that the combined result must be consistent, the correct answer names the reconciliation done at fan-in, not the parallel summaries.

2.5 Draft-then-critique

A model reviewing its own draft in the same pass tends to defend it. Splitting drafting from critique gives you a fresh-eyes review — ideally against an explicit checklist so the critique is objective, not vibes.

Example — a support reply. Draft the reply; then a critique step checks: does it answer every question the customer asked? is the tone on-brand? are any factual claims about the account unverified? Then revise. The critique step is also the natural home for a human review gate on higher-stakes replies.

2.6 Extract-then-transform

When a task needs to act on data buried in prose, first extract the data into a reliable structure, then transform. Doing both in one prompt means an extraction error and a transformation error blur together.

Example — expense processing:

Now the extraction is independently checkable (does the JSON match the receipt?) and the transform is deterministic policy logic you can test. Bundled together, a wrong total could be a misread amount or a misapplied rule — you cannot tell.

2.7 Choosing granularity — how small is too small

Decomposition has a cost: each step is a handoff, and handoffs add latency and places to lose context. Split a step when it earns its keep; stop when it does not.

Split further when…	Stop splitting when…
The step has two distinct jobs that fail separately	Each step already has exactly one job
You need a review or check between two parts	The split adds a handoff but no new inspection point
Different parts want different capabilities/models	Both parts want the same capability anyway
A part is reused by other workflows	The step is trivial and never reused

The goal is inspectable, single-job steps — not the maximum number of steps. Ten steps that each do a fifth of a job is its own anti-pattern.

2.8 Composing patterns

Real workflows combine patterns. The proposal in 2.3 is sequential overall, but step 5’s terms-check is a critique; a national brief is fan-out/fan-in whose fan-in is a draft-then-critique. Name the top-level pattern first, then the pattern inside each step.

Decision framework

The SPLIT test — decide whether and how to break a task apart. Ask five questions in order; the first “yes” tells you the pattern.

#	Question	If yes →
S — Sub-goals	Does the task have 2+ distinct sub-goals that could fail separately?	Decompose; go on to pick the pattern
P — Pipeline	Does each part depend on the previous part’s output?	Sequential
L — Lanes	Do independent pieces run in parallel and then combine?	Fan-out/fan-in (design the fan-in reconciliation)
I — Inspect	Does quality need a fresh-eyes review pass?	Draft-then-critique (write the checklist)
T — Transform-on-data	Must you act on data buried in prose?	Extract-then-transform

If S is “no” — one small job — keep it a single step; decomposition would only add overhead. Most real tasks answer “yes” to S and then to two or more of P/L/I/T, which is why patterns compose.

Common mistakes

Mistake	Why it happens	What to do instead
Writing one mega-prompt for a multi-goal task	It works in the quick demo	Split into named single-job steps you can inspect
Fixing a failing workflow by lengthening the prompt	The instruction feels incomplete	Find which sub-goal fails; split it out, don’t pad the blob
Reaching for a bigger model to fix opaque failures	Capability feels like the lever	Decompose first; often a cheaper model per step then works
Stapling fan-out results together as the “brief”	Concatenation looks like synthesis	Make the fan-in step reconcile, dedupe and total
Letting the model critique its draft in one pass	It is faster	Use a separate critique step against an explicit checklist
Blending extraction and transformation	One prompt seems simpler	Extract to structure first, then transform the structure
Over-splitting into a dozen trivial steps	“More steps = more robust” is assumed	Split only where a step has two jobs or needs a check between parts
Writing the executive summary first	It is the part you care about	Write summaries and abstracts last, from finished content

Scenario challenge

Scenario. Dan runs marketing ops. He built a ChatGPT workflow that takes a product brief and “produces a launch pack”: a blog post, three social variants, an email, an FAQ, and a one-line summary — all in a single long prompt with the brief pasted in. It demoed beautifully. In real use it is unreliable: sometimes the FAQ is missing, the social posts occasionally contradict a claim in the blog, and once the email quoted a price that appears nowhere else. When output is wrong, Dan cannot tell which part broke, so he keeps adding sentences to the prompt (“make sure the FAQ is included”, “keep prices consistent”) and it gets worse. His teammate suggests upgrading to the most capable model.

Expert reasoning trace.

Name the failure mode. This is a textbook mega-prompt: five distinct deliverables, competing sub-goals, opaque failures (missing FAQ = a dropped sub-goal; contradictory claims = no shared source of truth; a phantom price = a hallucinated fact with nowhere to catch it). Adding sentences is padding the blob — the exact anti-pattern.
Reject the bigger-model reflex. A more capable model might paper over some drops, but it does not make the failure visible or testable, and it costs more per run for a high-volume task. Capability is not the missing ingredient; structure is.
Pick the top-level pattern. The five assets are largely independent → fan-out/fan-in. But they must be consistent with a shared set of facts, so the fan-in cannot be concatenation.
Design the shared source of truth first (extract-then-transform). Step 0: extract the canonical facts from the brief — product name, price, three key claims, launch date — into a structured “fact sheet”. Every downstream asset is generated from the fact sheet, not from the raw brief, which kills the contradictory-claim and phantom-price bugs at the root.
Fan out the assets. Generate blog, social, email, FAQ, summary each as its own step, each consuming the fact sheet. A missing FAQ is now impossible to hide — it is a named step that either ran or did not.
Fan in with a critique. A final draft-then-critique step checks every asset against the fact sheet (no claim outside it; price matches) and against a completeness checklist (all five present). Write the one-line summary last, from the finished blog.
Route capabilities. Extraction is Luna-class structured work; drafting is a mid-tier model; the critique is a checklist pass. Cheaper per run and more reliable than the single mega-prompt on the top model.

The decision: replace the mega-prompt with extract-then-transform (fact sheet) → fan-out (five assets) → fan-in draft-then-critique (consistency + completeness), not a longer prompt and not a bigger model. Each failure Dan saw maps to a now-visible, now-testable step: dropped FAQ (fan-out step), contradictions and phantom price (shared fact sheet + critique).

Assessment traps

Trap	Why it is tempting	The discriminator
“Add more instructions to the prompt to fix the drops”	The prompt feels underspecified	Padding a mega-prompt worsens it; split the failing sub-goal into its own step
“Upgrade to the most capable model”	Capability feels like the fix for quality	A bigger model hides failures; it doesn’t make them visible or testable
“Concatenate the parallel summaries into the brief”	The pieces are already written	Fan-in must reconcile and total, not staple
“Have the model check its own draft in the same reply”	It is one fewer step	Same-pass self-review defends the draft; use a separate critique step
“Do extraction and the calculation in one prompt”	Simpler to write	Blended errors are undiagnosable; extract to structure, then transform
“Break it into as many steps as possible”	More steps sounds more robust	Over-splitting adds handoffs with no new inspection; split only where it earns it
“Write the executive summary first, it’s the priority”	It is what leadership reads	Summaries drift from content written after them; write them last

Practice questions

Each item states how many responses to select. Commit before revealing.

Q1 · A single long prompt produces a report that 'sometimes drops a section and is hard to debug'. What is the BEST fix? (Select one)

A. Add sentences to the prompt insisting every section appears B. Switch to the most capable model C. Decompose it into named single-job steps so each section is an inspectable step D. Lower the temperature

Answer: C. Dropped sections and undebuggable output are the mega-prompt signature; decomposing makes each section a step that visibly ran or did not. Padding the prompt (A) worsens the blob. A bigger model (B) hides failures rather than exposing them. Temperature (D) does not address structure.

Q2 · Each step's output is the next step's input. Which pattern is this? (Select one)

A. Fan-out/fan-in B. Sequential C. Draft-then-critique D. Extract-then-transform

Answer: B. A pipeline where B consumes A and C consumes B is sequential by definition. Fan-out/fan-in (A) runs pieces in parallel. Draft-then-critique (C) is a review pattern. Extract-then-transform (D) is a specific two-stage shape, not the general dependency chain.

Q3 · You must summarise ten independent reports into one consistent brief. Which pattern fits, and what is the critical step? (Select one)

A. Sequential; the critical step is the first summary B. Fan-out/fan-in; the critical step is the fan-in reconciliation that totals and dedupes C. Draft-then-critique; the critical step is the draft D. Extract-then-transform; the critical step is extraction

Answer: B. Independent pieces combined into one output is fan-out/fan-in, and consistency is enforced at the fan-in, which must reconcile rather than concatenate. Sequential (A) misfits independent work. Draft-then-critique (C) and extract-then-transform (D) are the wrong top-level shapes here.

Q4 · Why is a separate critique step better than asking the model to 'check your own answer' in the same reply? (Select one)

A. It uses fewer tokens B. A same-pass self-review tends to defend the draft; a separate pass gives fresh-eyes review, ideally against a checklist C. It is always faster D. It removes the need for any human review

Answer: B. Reviewing in the same pass carries the reasoning that produced the draft; a separate critique step (especially checklist-driven) is more objective. It is not about token count (A) or speed (C). It does not remove human review (D) — often the critique step is where the human gate lives.

Q5 · A workflow reads invoices and produces a reimbursement total, but wrong totals could be a misread amount or a misapplied rule. What decomposition fixes this? (Select one)

A. Draft-then-critique B. Extract-then-transform: extract structured fields first, then apply rules to the structure C. A single more detailed prompt D. Fan-out/fan-in over invoices

Answer: B. Separating extraction from the rule-based transform makes each independently checkable, so a wrong total is traceable to reading or logic. Draft-then-critique (A) reviews prose, not this. A detailed single prompt (C) keeps the errors blended. Fan-out (D) parallelises but still blends extract and transform per invoice.

Q6 · When should you STOP splitting a task into more steps? (Select one)

A. Never — more steps are always more robust B. When each step already has one job and a further split adds a handoff but no new inspection point C. After exactly three steps D. When the prompt gets long

Answer: B. Splitting earns its keep only when it separates distinct jobs or adds a needed check; beyond that it adds latency and context loss. ‘More is always better’ (A) and a fixed count (C) are wrong. Prompt length (D) is not the criterion.

Q7 · In a fan-out/fan-in workflow, the ten summaries are simply pasted together as the brief. What is wrong? (Select one)

A. Nothing — that is what fan-in means B. The fan-in must reconcile, dedupe and total, not concatenate; stapled summaries are not a synthesis C. There should be eleven summaries D. The fan-out step should be sequential

Answer: B. Fan-in is a synthesis step that resolves contradictions and totals figures; concatenation skips the actual combining work. Concatenation is not fan-in (A). The count (C) is irrelevant. Fan-out being parallel is correct (D).

Q8 · A proposal workflow keeps producing an executive summary that describes an earlier version of the body. What ordering fixes this? (Select one)

A. Write the executive summary first so it sets direction B. Write the executive summary last, generated from the finished body C. Write the summary and body in the same prompt D. Skip the summary

Answer: B. A summary must describe finished content, so it is written last in the sequence. Writing it first (A) guarantees drift as the body changes. Same-prompt generation (C) is the mega-prompt trap. Skipping it (D) fails the requirement.

Q9 · A teammate proposes fixing an unreliable mega-prompt by upgrading to the most capable, most expensive model. Why is decomposition usually the better first move? (Select one)

A. The expensive model is banned B. Decomposition makes failures visible and testable and often lets cheaper models handle each step; a bigger model just hides drops at higher cost C. Cheaper models are always more accurate D. Decomposition removes the need for review

Answer: B. The problem is structural, not capability; decomposing exposes and isolates failures and lets you route steps to lighter models. The expensive model is not banned (A). Cheaper models are not always more accurate (C). Decomposition does not remove review (D).

Q10 · Which TWO signals in a task description point toward extract-then-transform? (Select two)

A. The task must act on facts buried inside prose or documents B. The output must be consistent across ten parallel branches C. You need reliable structured data before applying rules or calculations D. A fresh-eyes review pass is the main quality lever E. Each step depends only on time of day

Answer: A and C. Extract-then-transform applies when you must pull structure out of prose and then act on that structure reliably. Consistency across parallel branches (B) points to fan-out/fan-in. A review pass (D) points to draft-then-critique. Time of day (E) is not a decomposition signal.

Q11 · A launch-pack workflow produces five assets that sometimes contradict each other on price and key claims. What is the ROOT-CAUSE fix? (Select one)

A. Tell the model to keep prices consistent B. Generate every asset from a single extracted ‘fact sheet’ (extract-then-transform) so all assets share one source of truth C. Generate the assets twice and keep the longer set D. Use a bigger model

Answer: B. Contradictions come from each asset inventing its own facts; a shared extracted fact sheet gives one source of truth all assets draw from. Telling it to be consistent (A) is padding the prompt. Generating twice (C) doubles cost without fixing the cause. A bigger model (D) does not create a shared source of truth.

Q12 · Which is the correct order of steps for a robust client proposal built from a discovery transcript? (Select one)

A. Executive summary → body → pricing → check B. Extract scope/dates → produce timeline and pricing (check totals) → draft body → write summary last → terms-check C. One prompt producing everything at once D. Pricing → summary → scope → body

Answer: B. Extract first, produce the numbers with a check where they’re created, draft from those, summarise last, then check against terms — each step inspectable and the summary matching the final body. Summary-first (A) drifts. One prompt (C) is the mega-prompt. Pricing before scope (D) has no inputs to price.

Q13 · A workflow was split into a dozen tiny steps, each doing a fraction of a job, and it is now slow and loses context between handoffs. What went wrong? (Select two)

A. Over-splitting added handoffs without new inspection points B. The task should never have been decomposed at all C. Steps should be merged where they share one job and need no check between them D. A bigger model would remove the handoffs E. Handoffs never cause context loss

Answer: A and C. Decomposition is a tool with a cost; splitting past the point of distinct jobs adds latency and context loss, so the fix is to merge steps that share a single job and need no intermediate check. The task did need some decomposition (B). A bigger model (D) doesn’t remove handoffs. Handoffs do cause context loss (E).

Q14 · You are designing a national brief from twelve regional reports, and it must reconcile terminology and totals. Which composed structure is BEST? (Select one)

A. Sequential only, one report after another B. Fan-out (extract-then-transform each report) → fan-in (draft-then-critique to synthesise and reconcile) C. Draft-then-critique on the raw twelve reports at once D. One mega-prompt with all twelve pasted in

Answer: B. Independent reports fan out (each extracted to a mini-structure), and the fan-in synthesises with a critique that reconciles terms and totals — patterns composed to fit. Pure sequential (A) ignores independence. Critiquing all twelve raw (C) skips per-report structure. One mega-prompt (D) is the anti-pattern.

Key takeaways

Decomposition turns “do everything” into named single-job steps that are individually inspectable, testable and cheap to run.
The mega-prompt fails opaquely: competing sub-goals, dropped parts, no place to check or review. Its fix is structure, not a longer prompt or a bigger model.
Four patterns cover most work: sequential, fan-out/fan-in, draft-then-critique, extract-then-transform — and they compose.
Fan-in must reconcile, not concatenate; critique must be a separate pass, ideally against a checklist; extraction must precede transformation so errors are traceable.
Give each step one job; a shared extracted “fact sheet” is the root-cause fix for cross-asset contradictions.
Choose granularity deliberately: split where a step has two jobs or needs a check between parts; stop when a split adds a handoff but no inspection.
Write summaries and abstracts last, from finished content.
Route each step to the lightest capability that does its job — decomposition often makes cheaper models sufficient per step.