Prompt decomposition

The "do everything" prompt

Here's a prompt many people write once they're comfortable with AI:

That's at least five different jobs: extraction, classification, prioritisation, executive writing, product thinking and customer-service writing. Each needs a different kind of attention and output format. Crammed into one prompt, the model tends to do all of them a bit: shallow categories, generic fixes, and replies that don't quite match the reviews.

Prompt decomposition is the skill of splitting a complex task into smaller sub-tasks, each with a clear input, a clear output, and a clear definition of "done".

Signs a prompt needs decomposing

• It contains several verbs that each describe a different deliverable ("analyse… and write… and suggest… and draft…").
• Different parts need different audiences or tones.
• Later parts depend on the results of earlier parts.
• When the output is bad, you can't tell which part went wrong.
• You'd assign the parts to different people if a human team were doing it.

How to decompose

1. Write down the final deliverable. What exactly do you need at the end?
2. Work backwards. What has to exist before you can produce it? And before that?
3. Define each sub-task's output. Make it concrete — a list, a table, a JSON object — so it can feed the next step.
4. Find dependencies. Which steps need others' results? Which are independent?
5. Decide how to run it. Sequentially in one conversation, as separate prompts (chaining), or with some steps done by code instead of a model.

Step 1 now has one job and a precise output. Step 2 might group complaints into themes and count them — or your code could do the counting. Step 3 writes the leadership report from the grouped data. Step 4 drafts replies using the original review text for each "angry" customer.

Decomposition inside a single prompt

You don't always need multiple calls. For moderate tasks, you can decompose within one prompt by listing explicit stages and asking for each stage's output under its own heading:

I'm choosing a laptop for video editing on a $1,500 budget.

Work through this in stages and label each one:
1. Requirements: list the specs that matter most for video editing and why.
2. Shortlist criteria: turn those into minimum thresholds.
3. Trade-offs: what I'd give up at this budget, ranked by impact.
4. Recommendation: what to prioritise when I compare models in shops.

Don't name specific models or prices — I'll check current listings myself.

This keeps the benefits of decomposition — focused stages, visible intermediate results — without the overhead of a pipeline. If one stage turns out weak, you can ask a follow-up about just that stage.

Choosing the right grain size

Too coarse and you're back to the "do everything" prompt. Too fine and you create lots of calls, more cost and latency, and more hand-offs where context can be lost. A practical rule: split where the output type, audience, or required skill changes, and where you'd want to inspect or test the result independently.

Decomposition and context

Each sub-task should get the context it needs and not much more. The reply-drafting step needs the specific review and your tone guidelines, not all 40 reviews. Trimming irrelevant context makes each step more focused and cheaper. But don't trim things a step truly needs — a common failure is a later step that lost a key constraint from the original request.