This is a do-this-then-that guide. If you have a complex task in front of you right now and want to run it through a model as a sequence of focused steps rather than one overloaded prompt, follow the steps below in order. Each one is concrete enough to act on immediately, and together they form a repeatable method you can apply to any sufficiently complex request.
Decomposition prompting works because narrow prompts get more careful answers and because intermediate results are checkable. This guide operationalizes that into a procedure: map the task, sequence the steps, run each step, verify as you go, and assemble the output. The procedure is deliberately mechanical so it holds up under real deadlines rather than requiring inspiration.
If you are new to the concept itself, start with Splitting Big Asks Into Steps a Model Can Actually Handle and come back here when you want the procedure. This piece assumes you already understand why decomposition helps and want to execute it cleanly.
Step 1: Map the Task Into Distinct Jobs
Before prompting anything, get the structure on paper.
List every distinct decision or transformation
Write out each separate piece of work the task contains. A distinct job is one that involves its own decision or transformation, like extracting information, restructuring it, drafting from it, or checking it. Aim for the real seams, not arbitrary slices.
Mark dependencies between jobs
Next to each job, note which other jobs it depends on. Extraction must precede the explanation that uses the extracted items. Mapping dependencies now prevents you from running a step before its inputs exist, which is a common and avoidable failure.
Decide what stays joined
If two jobs require joint reasoning to be correct, keep them together as one step. Not everything should be split. Marking these now keeps you from severing reasoning that needed to stay whole.
Step 2: Sequence the Steps
Turn the mapped jobs into an ordered list.
Order by dependency
Arrange the steps so each one runs only after the steps it depends on. Follow the dependency notes from Step 1. The result is a linear sequence where every step has the inputs it needs by the time it runs.
Define each step's input and output
For each step, write down what it takes in and what it produces. Making intermediates explicit, a labeled list, a set of fields, a structured draft, is what lets one step hand cleanly to the next. Loose, undefined outputs cause messy handoffs.
Add verification steps where errors are costly
Insert a checking step wherever a mistake would be expensive to let through, for example after extraction or before a final draft is used. Treat verification as its own step in the sequence, not an afterthought. This mirrors how careful domains build verification into the workflow, as in Making Legal Drafting With AI a Process Anyone Can Run.
Step 3: Run the First Step in Isolation
Now you start prompting, but only the first step.
Prompt narrowly for one job
Write a prompt that asks for exactly the first job and nothing else. Narrow scope is what produces the focused, careful answer that is the whole point. Resist bundling the next job in to save a round trip.
Constrain the output format
Specify the form you want the output in, matching the input the next step expects. If the next step needs a bulleted list, ask for a bulleted list. Matching formats across the seam keeps the handoff clean.
Read the result before continuing
Actually read the output. This is the checkpoint that makes decomposition valuable. If it is wrong, fix it here before it propagates. Pasting blindly into the next step forfeits the main advantage of the method.
Step 4: Chain the Remaining Steps
Repeat the pattern for each step, passing outputs forward.
Feed the prior output as input
Include the verified output of the previous step in the next prompt as its explicit input. State it clearly: "Using the following extracted items: [paste], do the next job." Clean handoffs are what make the chain reliable.
Keep the overall goal visible
In each prompt, briefly restate the end goal so the model does not optimize locally and drift. Long chains lose the thread when each step forgets what the whole task was for. A one-line reminder keeps it aimed.
Verify at the inserted checkpoints
When you reach a verification step, run it as its own prompt or your own manual check. Confirm the intermediate is correct before building further. Catching an error at its checkpoint is far cheaper than discovering it in the final output.
Step 5: Assemble and Final-Check
The last step produces the deliverable, but you are not done until you check the whole.
Produce the final output
Run the final step that assembles the deliverable from the verified intermediates. Because the inputs were checked along the way, this step has a strong foundation and tends to produce clean results.
Check the whole against the original goal
Read the final output against what you originally wanted, not just against the last step's input. Local correctness at every step does not guarantee the whole hits the goal; a final holistic check confirms it. For the conceptual depth behind this procedure, see The Definitive Guide to Decomposition Prompting for Hard Tasks.
Worked Example: A Multi-Part Analysis
Seeing the procedure run on a concrete task makes the abstract steps stick.
The task and its map
Suppose you must turn a long vendor contract into a risk briefing for a non-legal stakeholder. Mapping the distinct jobs gives four: (1) extract the obligations and liabilities, (2) flag the clauses that create the most exposure, (3) explain each flagged clause in plain language, and (4) assemble a short briefing. Obligations must be extracted before exposure can be judged, so the dependency order is clear.
Running the chain
Step one prompts only for a structured list of obligations and liabilities, output as labeled bullets. You read it and confirm nothing material was missed. Step two takes that list and asks which clauses create the most exposure and why, again as a list. You verify the reasoning before continuing. Step three takes the flagged clauses and asks for a plain-language explanation of each, which you check against the original contract for lost qualifiers. Step four assembles the briefing, restating the goal of informing a non-legal reader.
Why the chain beats one prompt
A single "summarize the risks in this contract for a non-lawyer" prompt would blur extraction, judgment, and simplification together, and you would not know which part failed if the briefing felt off. The chained version let you confirm the obligations were complete before any judgment was applied, and confirm the exposure judgment before any simplifying happened. Each checkpoint protected the steps built on top of it.
Common Execution Mistakes
Even with the procedure in hand, a few habits undermine it.
Bundling the next job to save time
The temptation to ask for two jobs in one prompt to save a round trip reintroduces exactly the overload decomposition removes. Keep each prompt narrow even when it feels slower; the focus is what buys the quality.
Skipping the read of an intermediate
Pasting one step's output into the next without reading it forfeits the method's core advantage. The checkpoints only protect you if you actually look at them.
Forgetting to final-check the whole
A chain where every step looked locally correct can still miss the original goal. The closing holistic check against what you actually wanted is not optional; it is what catches goal drift that the per-step checks cannot see.
Frequently Asked Questions
How many steps should the sequence have?
As many as there are distinct jobs that benefit from separation, usually three to six for most real tasks. Map the jobs first; the right number falls out of the structure rather than being chosen in advance. Avoid trivial steps that add handoffs without value.
What if a later step reveals an early step was wrong?
Go back, fix the early step's prompt, re-run it, and re-run the steps that depended on it. Because steps are separate, you re-run only the affected portion of the chain rather than the entire task.
Do I have to verify every intermediate?
Verify intermediates wherever a mistake would be costly to let through, and at least read every one. The whole advantage of decomposition is that intermediates are checkable, so skipping the checks wastes the method's main benefit.
How do I keep the model from drifting off task?
Restate the overall goal briefly in each step's prompt and define each step's expected input and output. Local restating and clear interfaces keep long chains aimed at the actual task instead of wandering.
Can I automate this chaining?
Yes, the same sequence can be wired into a script or tool that passes outputs between steps automatically. The procedure is the same; automation just removes the manual copy-paste. Keep the verification steps even when automating, since they are what protect quality.
When is this procedure overkill?
For a single, simple job, this procedure adds overhead without payoff; one good prompt is better. Use the full sequence when the task genuinely bundles several distinct jobs or when checking the work along the way matters.
Key Takeaways
- Map the task into distinct jobs and mark dependencies before writing any prompt.
- Sequence steps by dependency, define each step's input and output, and insert verification where errors are costly.
- Run the first step narrowly and in isolation, then read its result before continuing.
- Chain remaining steps by feeding verified outputs forward and restating the goal to prevent drift.
- Verify at checkpoints so errors are caught cheaply rather than discovered in the final output.
- Assemble the deliverable from checked intermediates and final-check the whole against the original goal.