Some requests are genuinely one task; others are several tasks wearing a single sentence. Decomposition is the skill of telling the difference.
When to decompose:
- The task has a natural pipeline shape (e.g., research → draft → review)
- You need to inspect or correct an intermediate result before moving forward
- The request bundles several distinct outputs that don't actually depend on being generated together
When not to decompose:
- The task is simple enough for Claude to reason through in a single pass — splitting it up here just adds overhead and more places for context to get lost, without improving the result
The clearest example: the self-correction pattern.
- Draft — generate a first pass
- Review — check the draft against explicit criteria (can even ask Claude to do this itself)
- Refine — improve based on what the review surfaced
Each stage is inspectable on its own, which is exactly the point — you can catch and correct an issue at the draft stage instead of discovering it buried in a finished deliverable.
For technically-minded readers: this generalizes the "prompt chaining" pattern from API workflows (separate calls for draft/review/refine), but the underlying judgment — does this task need staged checkpoints, or is one coherent pass enough — applies at any entry point, not just the API.