task-decomposition

What this skill does

# Task Decomposition

## Overview

Task decomposition breaks complex tasks into manageable, well-defined subtasks with clear dependencies, effort estimates, and parallelization opportunities. It covers hierarchical work breakdown structures (WBS), dependency graph construction, critical path analysis, task sizing, and identification of concurrent execution opportunities. Essential for planning multi-step implementations, project estimation, and autonomous loop task selection.

**Announce at start:** "I'm using the task-decomposition skill to break this work into a structured hierarchy with dependencies and estimates."

## Trigger Conditions

- Complex task needs to be broken into subtasks
- Dependency mapping is needed between work items
- Effort estimation is required for planning
- Parallelization opportunities need to be identified
- `/decompose` command invoked
- Transition from planning skill for complex plans
- Autonomous loop needs task selection guidance

---

## Phase 1: Scope Definition

**Goal:** Define clear boundaries for the decomposition.

1. Define the overall deliverable and acceptance criteria
2. Identify the boundaries (what is in scope, what is not)
3. Determine the decomposition granularity level
4. Identify stakeholders and their requirements
5. Establish constraints (time, resources, dependencies)

### Granularity Decision Table

| Context | Target Level | Typical Duration | Rationale |
|---------|-------------|-----------------|-----------|
| Autonomous loop (Ralph) | L3-L4 (Task/Subtask) | 15 min - 4 hours | ONE task per loop iteration |
| Sprint planning | L2-L3 (Story/Task) | 0.5-2 days | Sprint-sized work items |
| Roadmap planning | L0-L1 (Epic/Feature) | 2-8 weeks | High-level milestone tracking |
| Bug fix | L3-L4 (Task/Subtask) | 15 min - 2 hours | Focused, specific fixes |

### Granularity Levels

| Level | Name | Typical Duration | Example |
|-------|------|-----------------|---------|
| L0 | Epic | 2-8 weeks | "User authentication system" |
| L1 | Feature | 2-5 days | "OAuth2 login flow" |
| L2 | Story | 0.5-2 days | "Google OAuth provider integration" |
| L3 | Task | 1-4 hours | "Implement Google callback handler" |
| L4 | Subtask | 15-60 minutes | "Parse OAuth token response" |

**STOP — Do NOT proceed to Phase 2 until:**
- [ ] Deliverable and acceptance criteria are defined
- [ ] Scope boundaries are clear (in/out)
- [ ] Target granularity level is chosen
- [ ] Constraints are identified

---

## Phase 2: Hierarchical Breakdown

**Goal:** Decompose the work into a tree structure meeting the INVEST criteria.

1. Identify top-level work streams (epics or major components)
2. Break each work stream into features or milestones
3. Decompose features into implementable tasks
4. Apply the "2-hour rule" — no task should exceed 2 hours of focused work
5. Ensure each task has a clear definition of done
6. Verify MECE (Mutually Exclusive, Collectively Exhaustive) coverage

### The INVEST Criteria for Tasks

| Criterion | Question | Bad Example | Good Example |
|-----------|---------|-------------|-------------|
| **I**ndependent | Can this be done without waiting for others? | "Implement auth after DB is ready" | "Implement auth with mock DB" |
| **N**egotiable | Is the approach flexible? | "Use Redis for caching" | "Add caching layer for user sessions" |
| **V**aluable | Does completing this deliver value? | "Set up folder structure" | "Create user registration endpoint" |
| **E**stimable | Can you estimate the effort? | "Improve performance" | "Add database index for user lookup query" |
| **S**mall | Can one person finish it in < 2 hours? | "Build the dashboard" | "Create dashboard chart component for revenue data" |
| **T**estable | Can you verify it is done? | "Make it better" | "Response time < 200ms for /api/users" |

### MECE Verification

| Check | Question |
|-------|---------|
| Mutually Exclusive | Does any task overlap with another? (Should not) |
| Collectively Exhaustive | Do all tasks together cover the full deliverable? (Should) |
| No orphans | Does every task contribute to the deliverable? |
| No gaps | Is there any work needed that has no task? |

**STOP — Do NOT proceed to Phase 3 until:**
- [ ] All work streams are identified
- [ ] Tasks meet INVEST criteria
- [ ] MECE coverage is verified
- [ ] No task exceeds 2 hours

---

## Phase 3: Dependency Mapping

**Goal:** Build a directed acyclic graph (DAG) of task dependencies.

1. Identify input/output dependencies between tasks
2. Classify dependency types
3. Build a directed acyclic graph (DAG)
4. Identify the critical path (longest dependency chain)
5. Flag circular dependencies as errors to resolve
6. Mark external dependencies (API access, approvals, third-party)

### Dependency Types

| Type | Symbol | Meaning | Example |
|------|--------|---------|---------|
| Finish-to-Start (FS) | A -> B | B cannot start until A finishes | "Deploy" after "Build passes" |
| Start-to-Start (SS) | A => B | B can start when A starts | "Write docs" when "Write code" starts |
| Finish-to-Finish (FF) | A =>> B | B cannot finish until A finishes | "Testing" finishes after "Development" |
| Start-to-Finish (SF) | A ~> B | B cannot finish until A starts | Rare — shift handoff scenarios |

### Dependency Notation Format

```
Task 1: Set up database schema
Task 2: Create data access layer         [depends: 1]
Task 3: Implement API endpoints          [depends: 2]
Task 4: Write unit tests for DAL         [depends: 2]
Task 5: Write API integration tests      [depends: 3, 4]
Task 6: Create frontend components       [depends: none]
Task 7: Connect frontend to API          [depends: 3, 6]
Task 8: End-to-end testing               [depends: 5, 7]

Parallel tracks:
  Track A: 1 -> 2 -> 3 -> 5 -> 8
  Track B: 1 -> 2 -> 4 -> 5 -> 8
  Track C: 6 -> 7 -> 8
  Critical path: 1 -> 2 -> 3 -> 7 -> 8
```

### Circular Dependency Resolution

| Detection | Resolution |
|-----------|-----------|
| A depends on B, B depends on A | Break into smaller tasks that remove the cycle |
| A depends on B's interface, B depends on A's interface | Define interfaces first as a separate task |
| Tight coupling between components | Introduce an abstraction layer task |

**STOP — Do NOT proceed to Phase 4 until:**
- [ ] All dependencies are mapped
- [ ] No circular dependencies exist
- [ ] Critical path is identified
- [ ] External dependencies are flagged

---

## Phase 4: Parallelization Planning

**Goal:** Identify independent task clusters that can run concurrently.

1. Identify independent task clusters (no dependencies between them)
2. Group tasks by resource type (read, write, build, test)
3. Determine maximum parallelism based on resource constraints
4. Sequence tasks within each parallel track
5. Plan synchronization points (merge gates)

### Resource-Based Parallelism Limits

| Resource Type | Max Parallel | Rationale |
|--------------|-------------|-----------|
| Code reading / analysis | Unlimited | No side effects |
| File creation / editing | 3-5 | Avoid merge conflicts |
| Build / compile | 1 | Resource contention |
| Test execution | 1-2 | Shared state, ports |
| Database migrations | 1 | Sequential by nature |
| Documentation | Unlimited | Independent files |

### Parallelization Pattern Decision Table

| Pattern | When to Use | Example |
|---------|-----------|---------|
| Independent Clusters | Work streams with no shared state | Backend, Frontend, Infra |
| By Layer | Layers touch different files | API, Service, Data |
| By Feature Area | Independent vertical slices | Auth, Profile, Billing |
| By Task Type | Code, tests, docs touch different files | Implement, Test, Document |

### Synchronization Points

```
  +------+     +------+     +------+
  |Task A|     |Task B|     |Task C|
  +--+---+     +--+---+     +--+---+
     |            |            |
     v            v            v
  ======================================
     SYNC GATE: All Complete
     Verify: no conflicts, tests pass