Now liveThe Skillselion MCP - thousands of ranked skills, loaded into your agent mid-task. No install.Get it →
pixel-process-ug avatar

Task Decomposition

  • 65 installs
  • 1 repo stars
  • Updated March 16, 2026
  • pixel-process-ug/superkit-agents

Helps with ai & agent building tasks.

About

task-decomposition is a Claude Code skill for ai & agent building. It helps solo builders move faster with AI-assisted development.

  • task-decomposition
  • AI & Agent Building
  • AI-coding skill

Task Decomposition by the numbers

  • 65 all-time installs (skills.sh)
  • +2 installs in the week ending Aug 4, 2026 (Skillselion tracking)
  • Ranked #6,042 of 16,546 AI & Agent Building skills by installs in the Skillselion catalog
  • Data as of Aug 4, 2026 (Skillselion catalog sync)
npx skills add https://github.com/pixel-process-ug/superkit-agents --skill task-decomposition

Add your badge

Show developers this skill is listed on Skillselion. Paste this into your README.

Listed on Skillselion
Installs65
repo stars1
Last updatedMarch 16, 2026
Repositorypixel-process-ug/superkit-agents

What it does

Helps with ai & agent building tasks.

Files

SKILL.mdMarkdownGitHub ↗

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

ContextTarget LevelTypical DurationRationale
Autonomous loop (Ralph)L3-L4 (Task/Subtask)15 min - 4 hoursONE task per loop iteration
Sprint planningL2-L3 (Story/Task)0.5-2 daysSprint-sized work items
Roadmap planningL0-L1 (Epic/Feature)2-8 weeksHigh-level milestone tracking
Bug fixL3-L4 (Task/Subtask)15 min - 2 hoursFocused, specific fixes

Granularity Levels

LevelNameTypical DurationExample
L0Epic2-8 weeks"User authentication system"
L1Feature2-5 days"OAuth2 login flow"
L2Story0.5-2 days"Google OAuth provider integration"
L3Task1-4 hours"Implement Google callback handler"
L4Subtask15-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

CriterionQuestionBad ExampleGood Example
IndependentCan this be done without waiting for others?"Implement auth after DB is ready""Implement auth with mock DB"
NegotiableIs the approach flexible?"Use Redis for caching""Add caching layer for user sessions"
ValuableDoes completing this deliver value?"Set up folder structure""Create user registration endpoint"
EstimableCan you estimate the effort?"Improve performance""Add database index for user lookup query"
SmallCan one person finish it in < 2 hours?"Build the dashboard""Create dashboard chart component for revenue data"
TestableCan you verify it is done?"Make it better""Response time < 200ms for /api/users"

MECE Verification

CheckQuestion
Mutually ExclusiveDoes any task overlap with another? (Should not)
Collectively ExhaustiveDo all tasks together cover the full deliverable? (Should)
No orphansDoes every task contribute to the deliverable?
No gapsIs 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

TypeSymbolMeaningExample
Finish-to-Start (FS)A -> BB cannot start until A finishes"Deploy" after "Build passes"
Start-to-Start (SS)A => BB can start when A starts"Write docs" when "Write code" starts
Finish-to-Finish (FF)A =>> BB cannot finish until A finishes"Testing" finishes after "Development"
Start-to-Finish (SF)A ~> BB cannot finish until A startsRare — 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

DetectionResolution
A depends on B, B depends on ABreak into smaller tasks that remove the cycle
A depends on B's interface, B depends on A's interfaceDefine interfaces first as a separate task
Tight coupling between componentsIntroduce 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 TypeMax ParallelRationale
Code reading / analysisUnlimitedNo side effects
File creation / editing3-5Avoid merge conflicts
Build / compile1Resource contention
Test execution1-2Shared state, ports
Database migrations1Sequential by nature
DocumentationUnlimitedIndependent files

Parallelization Pattern Decision Table

PatternWhen to UseExample
Independent ClustersWork streams with no shared stateBackend, Frontend, Infra
By LayerLayers touch different filesAPI, Service, Data
By Feature AreaIndependent vertical slicesAuth, Profile, Billing
By Task TypeCode, tests, docs touch different filesImplement, Test, Document

Synchronization Points

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

STOP — Do NOT proceed to Phase 5 until:

  • [ ] Independent clusters are identified
  • [ ] Resource constraints are considered
  • [ ] Synchronization points are defined
  • [ ] Maximum parallelism is determined

---

Phase 5: Estimation and Prioritization

Goal: Estimate effort for each task and create an execution timeline.

T-Shirt Sizing to Hours

SizeHoursConfidenceExample
XS0.5-1hHighRename a variable, fix a typo
S1-2hHighAdd a simple endpoint, write a test
M2-4hMediumImplement a feature with known pattern
L4-8hLowNew feature with research needed
XL8h+Very LowMust be decomposed further

Estimation Heuristics

ScenarioMultiplierRationale
Known pattern1.2x base estimate20% buffer for unknowns
Unknown pattern2x base estimateAdd research spike task first
Integration work1.5x sum of componentsIntegration is harder than parts
First-time technology3x "if I knew how" estimateLearning curve
Bug fixesTime-box 2h investigationThen re-estimate

Three-Point Estimation

Expected = (Optimistic + 4 * Most Likely + Pessimistic) / 6

Example:
  Optimistic:  2 hours (everything goes smoothly)
  Most Likely: 4 hours (normal development pace)
  Pessimistic: 10 hours (major unexpected issues)
  Expected:    (2 + 16 + 10) / 6 = 4.7 hours

Prioritization Decision Table

FactorWeightHow to Evaluate
On critical pathHighestDelays here delay everything
Blocks other tasksHighUnblocking multiplies throughput
Business valueHighUser-facing impact
Risk reductionMediumDe-risks unknowns early
Quick winMediumLow effort, high morale
Nice to haveLowOnly after core work is done

---

Work Breakdown Structure Template

# WBS: [Project Name]

## 1. [Work Stream A]
### 1.1 [Feature]
- [ ] 1.1.1 [Task] — Est: 2h — Deps: none — Priority: P0
- [ ] 1.1.2 [Task] — Est: 1h — Deps: 1.1.1 — Priority: P0
- [ ] 1.1.3 [Task] — Est: 3h — Deps: 1.1.1 — Priority: P1

### 1.2 [Feature]
- [ ] 1.2.1 [Task] — Est: 1h — Deps: none — Priority: P0
- [ ] 1.2.2 [Task] — Est: 2h — Deps: 1.2.1, 1.1.2 — Priority: P1

## 2. [Work Stream B]
### 2.1 [Feature]
- [ ] 2.1.1 [Task] — Est: 1h — Deps: none — Priority: P0
- [ ] 2.1.2 [Task] — Est: 4h — Deps: 2.1.1 — Priority: P0

## Summary
- Total tasks: N
- Estimated total effort: Xh
- Critical path duration: Yh
- Max parallelism: Z tracks
- External dependencies: [list]

---

Critical Path Analysis

How to Find the Critical Path

1. List all tasks with durations and dependencies 2. Forward pass: calculate earliest start (ES) and earliest finish (EF) 3. Backward pass: calculate latest start (LS) and latest finish (LF) 4. Float = LS - ES (tasks with zero float are on the critical path) 5. The critical path is the longest chain through the dependency graph

Optimization Strategies

StrategyWhenEffectRisk
ParallelizeIndependent tasks on critical pathReduces calendar timeLow
Fast-trackOverlap sequential tasksReduces durationMedium — may cause rework
CrashAdd resources to critical tasksReduces durationMedium — coordination cost
Scope reductionRemove non-essential tasksReduces total workLow — if non-essential is correct
Spike firstUnknown tasks blocking the pathDe-risks estimatesLow

---

Anti-Patterns / Common Mistakes

Anti-PatternWhy It FailsCorrect Approach
Tasks too large to estimate"Build the backend" is not a taskDecompose until estimable (< 2h)
Missing dependenciesSurface during implementation, cause reworkMap ALL dependencies upfront
Circular dependenciesIndicate unclear architectureBreak the cycle with interface tasks
All tasks sequentialNo parallelism possibleIdentify independent clusters
Estimation without decompositionGuessing at L0 level, always wrongEstimate at leaf level, sum up
Ignoring external dependenciesBlock progress unexpectedlyFlag and plan for them
Over-decompositionNoise, not signal (50 subtasks for a form)Stop at meaningful, testable units
Ignoring critical pathPriorities work on non-critical tasksAlways prioritize critical path
Not re-estimatingEstimates drift as you learnRe-estimate after each phase
Tasks without acceptance criteriaCannot verify completionEvery task has definition of done

---

Anti-Rationalization Guards

<HARD-GATE> Do NOT skip dependency mapping. Do NOT leave tasks larger than 2 hours. Do NOT estimate without decomposing first. Every task must have dependencies, estimates, and acceptance criteria. </HARD-GATE>

If you catch yourself thinking:

  • "I can estimate the whole thing without breaking it down..." — No. Decompose first.
  • "Dependencies are obvious, I don't need to map them..." — Map them. Hidden dependencies cause failures.
  • "This task is fine at 8 hours..." — Decompose it. XL tasks must be broken down.
  • "The critical path doesn't matter for small projects..." — It does. It tells you what to prioritize.

---

Subagent Dispatch Opportunities

Task PatternDispatch ToWhen
Parallelizable leaf tasks identified during decompositionParallel subagents via Agent toolWhen tasks have no shared dependencies
Architecture analysis of task boundariesplanner agentWhen decomposition reveals cross-cutting concerns
Validation of decomposition completenessspec-reviewer agentWhen task tree is complete but unverified

Mark each decomposed task with a parallelizable: yes/no flag in the output table. Follow the dispatching-parallel-agents skill protocol when dispatching.

---

Integration Points

SkillRelationshipWhen
planningUpstream — provides the plan to decomposeComplex plans need WBS
task-managementDownstream — receives decomposed tasksFor execution tracking
dispatching-parallel-agentsDownstream — receives parallelizable clustersFor concurrent execution
autonomous-loopDownstream — task selection from WBSRalph task selection
executing-plansDownstream — batch creation from WBSPlan execution
subagent-driven-developmentDownstream — independent tasks for subagentsDelegated implementation
spec-writingComplementary — specs inform decompositionUnderstanding requirements

---

Concrete Examples

Example: Decomposition of "Add User Authentication"

# WBS: User Authentication

## 1. Core Auth
### 1.1 Token Management
- [ ] 1.1.1 Implement JWT generation — Est: 1h — Deps: none — P0
- [ ] 1.1.2 Implement JWT validation — Est: 1h — Deps: 1.1.1 — P0
- [ ] 1.1.3 Implement refresh token rotation — Est: 2h — Deps: 1.1.2 — P1

### 1.2 Auth Middleware
- [ ] 1.2.1 Create auth middleware — Est: 1h — Deps: 1.1.2 — P0
- [ ] 1.2.2 Add role-based access control — Est: 2h — Deps: 1.2.1 — P1

## 2. Auth Endpoints
### 2.1 Registration
- [ ] 2.1.1 POST /auth/register endpoint — Est: 1h — Deps: 1.1.1 — P0
- [ ] 2.1.2 Email validation — Est: 30m — Deps: none — P0

### 2.2 Login
- [ ] 2.2.1 POST /auth/login endpoint — Est: 1h — Deps: 1.1.1, 1.2.1 — P0
- [ ] 2.2.2 POST /auth/refresh endpoint — Est: 1h — Deps: 1.1.3 — P1

## Summary
- Total tasks: 8
- Estimated total effort: 10.5h
- Critical path: 1.1.1 -> 1.1.2 -> 1.2.1 -> 2.2.1 (4h)
- Max parallelism: 3 tracks (Token, Middleware, Endpoints)
- External dependencies: none

---

Skill Type

RIGID — Follow the decomposition phases in order. Every task must meet the INVEST criteria and have explicit dependencies, estimates, and acceptance criteria. The dependency graph and critical path analysis are mandatory for multi-day work.

Related skills

This week in AI coding

Five minutes, every Monday - the tools, releases and tactics for developers.

unsubscribe anytime.