decomposition

# Work Decomposition

This skill guides the process of breaking higher-level work into actionable lower-level items.

## The Decomposition Chain

```
Vision: "Make X a better experience"
    ↓
Strategy: "Focus on performance first"
    ↓
Initiative: "Reduce page load time by 50%"
    ↓
Tasks: "Profile slow queries", "Add caching layer", "Optimize images"
```

Each level breaks work above it into concrete, actionable pieces at appropriate scope.

## When to Decompose

Decompose **ahead of capacity**, not upfront:

- When team's current backlog is nearing its end
- During tail end of current work to prepare next batch
- When backlog is getting low (signal to look up and pull work down)

**Avoid**: Decomposing everything upfront (waterfall). Have work ready when capacity frees up, not entire project planned before starting.

## The Decompose Phase

Initiatives have an explicit "decompose" phase:

```
discovery → design → ready → decompose → active → completed
```

### Why Decompose is Explicit

The decompose phase creates a **visible buffer**:
- Solutions can pile up waiting to be broken into tasks
- Tracks how long things sit here
- Makes bottlenecks visible in multi-team environments

**Don't skip to decompose early.** Premature decomposition leads to tasks that solve wrong problems, rework when design changes, wasted effort.

## Sizing by Scope, Not Time

Size by scope and impact, not implementation time:

### Tasks: Atomic Units
- **Scope**: Discrete, completable piece with clear done criteria
- **Impact**: Moves the needle on parent initiative
- **Independence**: Can be worked without constant coordination
- **Examples**: "Add caching layer", "Write migration script", "Update API endpoint"

**If a task has meaningful subtasks**, it should probably be an initiative.

### Initiatives: Capability Increments
- **Scope**: Creates fundamental increment in capability
- **Impact**: Meaningfully changes what system can do
- **Coherence**: Tasks within work toward unified o