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
└── Infrastructure Domain
    ├── OAuth provider setup
    └── Environment config

Step 2: Map Dependencies

Create dependency graph:

[DB Schema] ──┬──> [Auth Middleware] ──> [Integration Tests]
              │
              ├──> [JWT Service]
              │
              └──> [User Validation]

[Login UI] ────────────────────────────> [E2E Tests]
[Registration UI] ─────────────────────> [E2E Tests]

Step 3: Identify Parallel Lanes

Group independent tasks into lanes:

Lane 1 (Backend)     Lane 2 (Frontend)    Lane 3 (Infra)
─────────────────    ─────────────────    ─────────────────
[DB Schema]          [Login UI]           [OAuth Setup]
     │               [Registration UI]    [Env Config]
     ▼               [Reset UI]
[Auth Middleware]
[JWT Service]
[User Validation]

Step 4: Define Integration Points

Where lanes must synchronize:

Sync Point 1: API Contract
- Backend exposes POST /auth/login
- Frontend implements against contract
- Both can develop in parallel with mock

Sync Point 2: Integration Testing
- All lanes complete
- Run integration test suite
- Fix cross-cutting issues

Task Template

Use this template for each decomposed task:

## Task: [Clear, action-oriented title]

**Lane**: [Backend | Frontend | Infra | Data]
**Size**: [Small | Medium]
**Dependencies**: [None | Task IDs that must complete first]

### Context
[1-2 sentences on why this task exists]

### Deliverables
- [ ] [Specific artifact 1]
- [ ] [Specific artifact 2]

### Acceptance Criteria
- [ ] [Measurable criterion 1]
- [ ] [Measurable criterion 2]
- [ ] Tests pass
- [ ] Linting clean

### Notes
[Any implementation hints or decisions already made]

Parallelization Patterns

Pattern 1: Component Parallel

Split by UI component when each is independent:

/leader --team-size=3 --mode=parallel

Task 1: Build LoginForm component
Task 2: Build RegistrationForm component
Task 3: Build PasswordResetForm component

Pattern 2: Layer Parallel

Split by architectural layer:

/leader --team-size=3 --mode=parallel

Task 1: Implement API endpoints (backend)
Task 2: Implement UI components (frontend)
Task 3: Set up infrastructure (devops)

Pattern 3: Hybrid

Critical path sequential, supporting work parallel:

/leader --team-size=3 --mode=hybrid

Sequential (Critical Path):
  Task 1: Design database schema
  Task 2: Implement core API

Parallel (After Task 1):
  Task 3: Build UI components
  Task 4: Write integration tests
  Task 5: Set up monitoring

Anti-Patterns to Avoid

Over-Decomposition

BAD: 20 tiny tasks that have coordination overhead
GOOD: 3-5 meaningful tasks per engineer

Hidden Dependencies

BAD: "Task B assumes Task A's schema design"
GOOD: "Task B depends on Task A (schema must be finalized)"

Unclear Ownership

BAD: "Someone should handle auth"
GOOD: "Engineer 2 owns auth middleware (Task B)"

Missing Integration Plan

BAD: 5 parallel tasks with no sync point
GOOD: Parallel tasks + defined integration checkpoint

Output Format

When decomposing tasks, produce:

## Task Decomposition: [Feature Name]

### Overview
- Total tasks: N
- Parallel lanes: M
- Critical path: [sequence]
- Estimated parallelism: X%

### Dependency Graph
[ASCII diagram showing task relationships]

### Task Breakdown

#### Lane 1: [Domain]
| ID | Task | Size | Deps | Engineer |
|----|------|------|------|----------|
| T1 | ... | Medium | None | Senior 1 |
| T2 | ... | Small | T1 | Senior 1 |

#### Lane 2: [Domain]
| ID | Task | Size | Deps | Engineer |
|----|------|------|------|----------|
| T3 | ... | Medium | None | Senior 2 |

### Integration Points
1. After T1, T3: API contract validation
2. After all: Full integration test

### Execution Plan
Phase 1: T1, T3, T5 (parallel)
Phase 2: T2, T4 (parallel, after Phase 1)
Phase 3: Integration (sequential)

Checklist

Before finalizing decomposition:

Each task has single responsibility
Dependencies are explicit (not assumed)
No task exceeds "Medium" size
Integration points defined
Ownership is clear
Acceptance criteria are testable
Critical path identified
Parallelism opportunities maximized

task-decomposition