task-decomposition

This skill provides methodology for decomposing complex tasks into independent, parallelizable units that can be executed by multiple engineers simultaneously.

## When to Invoke This Skill

Automatically activate for:
- Complex features requiring multiple components
- Large refactoring spanning many files
- Multi-domain work (frontend + backend + database)
- Any task where "this could be parallelized" applies
- Planning sprints or implementation roadmaps

## Task Decomposition Principles

### 1. Independence First

Tasks must be independent to run in parallel:

```
GOOD: Each task can complete without waiting
┌─────────────────┐  ┌─────────────────┐  ┌─────────────────┐
│ Task A: Auth UI │  │ Task B: Auth API│  │ Task C: DB Schema│
│ (no deps)       │  │ (no deps)       │  │ (no deps)        │
└─────────────────┘  └─────────────────┘  └─────────────────┘

BAD: Sequential dependency chain
Task A → Task B → Task C (no parallelism possible)
```

### 2. Clear Boundaries

Each task must have:
- **Single responsibility**: One deliverable per task
- **Defined inputs**: What data/context is needed
- **Expected outputs**: What artifact is produced
- **Acceptance criteria**: How to verify completion

### 3. Right-Sized Tasks

| Size | Duration | Complexity | Assignment |
|------|----------|------------|------------|
| Small | < 30 min | Single file, routine | Junior engineer |
| Medium | 30-60 min | Multi-file, some decisions | Senior engineer |
| Large | 1-2 hours | Cross-cutting, architectural | Lead or split further |

**Rule**: If a task is "Large", decompose it further.

## Decomposition Framework

### Step 1: Identify Domains

Map the work to distinct domains:

```
Feature: User Authentication
├── Frontend Domain
│   ├── Login form component
│   ├── Registration flow
│   └── Password reset UI
├── Backend Domain
│   ├── Auth middleware
│   ├── JWT token service
│   └── User validation
├── Data Domain
│   ├── User schema
│   ├── Session storage
│   └── Migration scripts