Task decomposition strategies

Choose the decomposition pattern that matches how predictable the work is.

Use prompt chaining for known workflows

When the steps are predictable, fix them. A code review might run: analyze each file on its own, then run a separate pass across files.

The reason to split is attention dilution. One prompt carrying twenty files and every review concern gets shallower results than several focused passes. Each pass has a job and the context to do it.

The cross-file pass is not optional. Per-file analysis structurally cannot see an inconsistency that only exists between files.

Four people each proofread their own section of a group paper and every section comes back clean. The paper still calls them participants in one section and subjects in another, because that inconsistency is not inside any single section.

Use dynamic decomposition when the work is discovered as it proceeds

"Add comprehensive tests to this legacy codebase" cannot be planned in advance, because the plan depends on what the codebase turns out to be.

Map the structure first. Identify high-impact areas. Then build a prioritized plan — and let it change as dependencies surface. Subtasks are generated from findings rather than guessed at the start.

Choosing

Ask whether you can enumerate the steps before starting.

If yes, chain them; the predictable order is useful. If the next step depends on what you discover, use dynamic decomposition. A fixed pipeline may otherwise miss important work or perform steps that are not needed.