Decomposition Instructions

Prompting an agent to decompose a complex task before starting it is different from prompting it to plan. Decomposition produces a subtask list with dependency relationships. Planning produces a sequence of actions. Decomposition happens at the task level; planning happens at the action level. For complex multi-step work, decomposition should precede planning.

# Decomposition instruction

Task: [complex task description]

Before taking any action, decompose this task into subtasks:

For each subtask, specify:
- Subtask ID: (S1, S2, S3, ...)
- Description: what this subtask accomplishes
- Depends on: which other subtasks must be complete before this one starts (or "none")
- Output: what this subtask produces (specific artifact or result)
- Tool(s) required: which tools will be used

Evaluation criteria for a good decomposition:
□ Each subtask is independently executable (given its dependencies are met)
□ Each subtask has a clear, verifiable output
□ Dependencies are minimal (parallel where possible)
□ No subtask duplicates the work of another
□ The full set of subtasks, when complete, satisfies the original task

Present the decomposition. I will review and approve before execution begins.

1. Evaluation Criteria in the Prompt Include the quality criteria for a good decomposition in the prompt. Without criteria, the model produces a decomposition but you have no basis for evaluating it. With criteria, you and the model have a shared standard — and the model can self-evaluate before presenting.
2. Catching Over-Decomposition Over-decomposition breaks a task into more subtasks than necessary, creating coordination overhead with no quality benefit. Signs: subtasks that each consist of a single API call, subtasks whose dependencies form a purely sequential chain with no parallelism. Consolidate when two subtasks are always sequential and neither produces an independent artifact.