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]

Lane 2: [Domain]

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