Task Decomposition - Breaking Down Complexity for AI | AI Skill Library

What This Skill Is

Task Decomposition is the practice of breaking down complex objectives into smaller, independently executable units. Instead of presenting AI with a monolithic request that tries to do everything at once, you structure the work into clear subtasks that build toward the final outcome.

Decomposition operates on the principle that complex problems become tractable when divided into focused components. Each subtask has a specific purpose, defined inputs, and expected outputs. When executed in sequence, these subtasks collectively solve the larger problem.

This skill differs from simply listing steps. Decomposition considers dependencies between subtasks, identifies decision points, and establishes clear handoff criteria. It creates a roadmap where each segment is independently verifiable before proceeding to the next.

Why This Skill Matters

Without task decomposition, AI interactions with complex problems tend to fail in predictable ways. The AI attempts to address all aspects simultaneously, resulting in shallow coverage of each. Critical steps get missed. Assumptions go unexamined. The output becomes a patchwork where some parts are excellent while others are completely overlooked.

Decomposition forces explicit consideration of what the work actually entails. When you decompose properly, you discover hidden dependencies. You realize that step B requires information from step A. You notice that step D has three different possible outcomes, each requiring a different approach for step E. These insights emerge during decomposition, especially when applying Abstraction principles.

The cognitive load on AI also decreases dramatically. Instead of holding an entire complex problem in working memory, AI processes one focused subtask at a time. Each subtask gets appropriate attention and depth. The final output reflects systematic coverage rather than scattered attempts to address everything at once.

Reproducibility improves as well. When a complex task is decomposed, you can trace exactly which subtask produced which result. If something goes wrong, you isolate the failure point. If something works well, you identify what made it successful. This visibility is impossible when work happens as an opaque monolith.

Core Concepts

Orthogonality

Orthogonal subtasks address different aspects of the problem without overlapping. When subtasks overlap, you create redundancy and inconsistency—the same work gets done twice, or done differently in different places. Good decomposition ensures that each piece has unique responsibility.

Think of software functions: a well-designed function does one thing well. Task decomposition applies the same principle. One subtask might handle data gathering, another handles analysis, and a third handles formatting. These don't overlap—they're orthogonal.

Dependency Mapping

Dependencies determine execution order. Some subtasks cannot start until others finish. Others can run in parallel. Dependency mapping makes these relationships explicit so you don't discover halfway through that you're missing a critical input.

Dependencies form a directed acyclic graph—no circular relationships allowed. If A depends on B, and B depends on C, then C cannot depend on A. Circular dependencies indicate that decomposition needs refinement; the subtasks aren't actually independent.

Granularity

Granularity refers to the size of subtasks. Too coarse, and subtasks are still complex enough to fail. Too fine, and you're managing micro-operations that add overhead without benefit. The right granularity is the smallest unit that can be independently verified.

A practical test: can you clearly state whether a subtask succeeded or failed? If success is ambiguous, the subtask is too large. If you're decomposing "open a file" into smaller steps, the subtask is too small.

Handoff Criteria

Handoff criteria define when a subtask is complete and what it produces. This isn't just about finishing—it's about producing a specific artifact that the next subtask consumes. Without clear handoff criteria, subtasks blur together and you lose the benefits of decomposition.

Handoff criteria might be a data structure, a decision, a validated result, or a documented state. What matters is that the next subtask can verify it received what it needed before proceeding. This validation step connects closely with Output Validation practices.

How This Skill Is Used

Task decomposition transforms a vague, complex request into a structured execution plan. The process begins with understanding the objective, then systematically breaking it down until each component is directly actionable.

Start by stating the overall goal in concrete terms. What does success look like? What are the deliverables? This clarity prevents decomposition from drifting away from the actual purpose.

Identify the major phases of work. Most complex tasks have natural stages: research, design, implementation, validation, documentation. These high-level phases become your first decomposition pass.

For each phase, identify the specific activities required. Research might involve source gathering, reading, and synthesis. Implementation might involve component development, integration, and testing. Each activity becomes a subtask.

Examine each subtask for further decomposition. Can it be stated as a direct action with clear inputs and outputs? If not, decompose further. If yes, you've reached the appropriate granularity.

Map dependencies between subtasks. Which must happen first? Which can happen in parallel? Where are the decision points that affect subsequent steps? This mapping produces the execution sequence.

Define handoff criteria for each subtask. What does this subtask produce? How does the next subtask verify it received the correct input? These criteria create checkpoints throughout the work.

Review the complete decomposition for orthogonality. Are any subtasks overlapping? Are gaps evident where work falls through the cracks? Refine until each piece has unique responsibility and all required work is covered.

Common Mistakes

Mistake: Decomposing by Activity Rather Than Outcome

Subtasks like "research," "think about," "analyze" describe activities but not outcomes. These decompositions fail because you can't verify whether the activity achieved its purpose.

Better decomposition specifies outcomes: "identify three viable approaches," "evaluate each approach against criteria X and Y," "document the rationale for the recommended approach." These are verifiable.

Mistake: Creating False Dependencies

Not everything needs to happen sequentially. Over-constraining dependencies makes work take longer than necessary. Just because you naturally think of step A before step B doesn't mean A must complete before B starts.

Identify true dependencies (B requires data from A) versus artificial dependencies (you listed A before B). Parallelizing independent subtasks significantly reduces execution time. This dependency mapping is a core aspect of Planning workflows.

Mistake: Mixing Abstraction Levels

Decomposition should stay at a consistent level. If one subtask is "implement authentication system" and another is "write unit test for password validation function," you're mixing architectural and implementation levels.

Keep all subtasks at the same granularity. If you need to decompose "implement authentication system" into implementation-level details, do so as a separate pass, not mixed with higher-level subtasks.

Mistake: Ignoring Error Handling

Decomposition often assumes everything works correctly. The plan shows A → B → C, but doesn't account for what happens if A fails or returns unexpected results.

Robust decomposition includes error-handling subtasks. What happens if data gathering returns no results? What if analysis produces ambiguous findings? Include subtasks that detect and handle these conditions, which is essential for effective Error Recovery.

Mistake: Decomposing Without Context

Subtasks exist in isolation only in artificial examples. In reality, each subtask operates within constraints, uses specific resources, and produces outputs for specific consumers. Decomposition that ignores this context produces subtasks that don't fit together.

Each subtask should specify its context: what information does it use? What constraints does it operate under? Who consumes its output? Context-aware decomposition produces subtasks that actually connect.

When This Skill Is Needed

Task decomposition becomes necessary when the gap between request and execution is too large for direct prompting. You notice this gap when AI responses are incomplete, shallow, or miss critical aspects of the problem.

Complex problem-solving requires decomposition. Debugging a distributed system, designing a software architecture, or planning a product launch all involve multiple interlocking components. Attempting these as monolithic tasks produces scattershot results.

Multi-stage workflows require decomposition by definition. If the work naturally breaks into phases like research → analysis → design → implement, each phase becomes a decomposition boundary.

Tasks with decision points require decomposition. When early decisions affect subsequent steps, you need explicit subtasks for decision-making and branching. Without decomposition, the AI tries to pursue all branches simultaneously or arbitrarily picks one without justification.

Learning and exploration tasks benefit from decomposition. When you're studying a new topic, decomposing "learn about X" into "identify key concepts," "understand foundational principles," "explore practical applications" creates structure and ensures comprehensive coverage.

Tasks requiring validation or quality checks need decomposition at decision points. "Generate code" decomposes usefully into "generate initial implementation," "validate against requirements," "address edge cases," "optimize performance." Each validation point becomes a subtask boundary, where Evaluation becomes critical.

How This Skill Connects to Other Skills

Task decomposition works in concert with several other cognitive skills. Understanding these connections helps you apply decomposition effectively.

Decomposition builds on Abstraction. You need to understand the essential structure of a problem before you can decompose it. Abstraction identifies the core components; decomposition defines how to address them. Poor abstraction produces messy decomposition with overlapping responsibilities.

Decomposition precedes reasoning. Once a task is decomposed, reasoning skills address each subtask. Reasoning without decomposition tries to process too much at once; decomposition gives reasoning focused, tractable units.

Decomposition enables Planning. You cannot plan effectively until you know what the work consists of. Decomposition produces the task list that planning sequences and schedules. Planning without decomposition produces unrealistic timelines because it doesn't account for what each task actually entails.

Decomposition integrates with context management. Each subtask needs specific context to execute well. Decomposition identifies what context each subtask requires, enabling targeted context provision rather than overwhelming context dumps.

Decomposition supports Iteration. When work is decomposed, you can iterate on specific subtasks without redoing everything. Iteration without decomposition often requires starting from scratch because you can't isolate what needs improvement.

Skill Boundaries

Task decomposition has limitations. Recognizing what decomposition cannot do prevents misapplication.

Decomposition does not execute the work. Breaking down tasks doesn't complete them. You still need reasoning, analysis, and domain expertise to address each subtask. Decomposition is structure, not substance.

Decomposition cannot compensate for unclear objectives. If you don't know what you're trying to achieve, decomposition won't reveal it. The process exposes ambiguity but doesn't resolve it—you need to clarify the objective before decomposing.

Decomposition has diminishing returns. Beyond a certain point, further decomposition adds overhead without benefit. If you're breaking down "write a function" into "think about the function," "decide the name," "write the signature," you're micro-decomposing.

Decomposition doesn't eliminate the need for domain knowledge. Subtasks still require expertise to execute. Decomposition organizes the work but doesn't make the work itself easier—you still need to understand what you're doing.

Decomposition cannot serialize inherently parallel work. If multiple aspects of a problem are truly independent, forcing them into a sequential decomposition loses efficiency. Recognize when parallel decomposition is appropriate rather than defaulting to sequential.

Related Skills

Prerequisite Skills

Abstraction: Need abstraction ability to recognize task boundaries and extract essential components before breaking them down.

Complementary Skills

Reasoning: Decomposition and reasoning reinforce each other in problem-solving—decomposition creates focused units for reasoning to address.

Planning: Decomposed tasks create the units of work that planning sequences and schedules; planning operates at the right granularity when tasks are properly decomposed.