task-decomposition

npx github:yingkitw/skillsheet --remote --tool claude-code --only task-decomposition

name: task-decomposition description: Decomposes a goal along three axes — hierarchical breakdown (goal → phases → subtasks), sequential ordering (must-finish-before), and parallel grouping (can-run-together) — into a single artifact that combines a WBS tree, a critical path, and parallel waves. Use when breaking a goal into work items, sequencing or parallelizing execution, or when the user mentions sub-tasks, parallel work, dependencies, sequencing, or WBS. category: implementation keywords: wbs, work-breakdown, dependency-graph, parallel, sequencing, subtasks, planning, hierarchy

Task Decomposition

A goal is a sentence; the work is a graph with three views. Hierarchy answers what decomposes into what (a tree from goal down to actionable leaves). Sequence answers what must finish first (a critical-path chain — edges that exist because of real ordering constraints). Parallel answers what can run together (waves of leaves whose prereqs are all already satisfied). Combine the three and you get a plan you can dispatch, not a checklist you can only walk top-to-bottom.

When to apply

Use when a goal is too large or too vague to act on directly; when multiple agents or people will share the work and you need to decide who starts when; when a plan keeps stalling because some steps were ordered by habit instead of by necessity; or when the user asks for a work breakdown, a project plan, parallel work, task dependencies, a sequencing diagram, or a WBS.

Workflow

1. Pin the outcome — write the goal's success criterion in one sentence. Every leaf must trace back to it. If you can't name the outcome, decompose the goal statement first (often it has multiple goals hiding in one sentence).
2. Build the hierarchy — top-down: split the goal into 2–5 phases (major slices of value, e.g. Backend / API / Wiring / Tests / Docs); split each phase into sub-goals (concrete deliverables within the slice); split sub-goals into leaves (actionable tasks — verb + object). Stop when every leaf can be assigned to one owner and finished in one sitting.
3. Enumerate leaves — for each leaf, record:
   • What — one verb + one object ("write contract test for parseUser")
   • Inputs — artifacts or decisions it consumes (an API spec, a design, a sibling leaf's output)
   • Outputs — artifacts or decisions it produces (a file, an interface, a verified behavior)
   • Estimate — rough size (S < 1h, M < half day, L > half day). Don't pretend precision.
   • Owner — who/what can do it (human role, agent, or external dependency).
4. Draw the dependencies — for each leaf, list the other leaves that must complete first (its prereqs). A leaf with no prereqs is a root; a leaf no other leaf depends on is a leaf in the graph sense. Edges go from prereq → dependent.
5. Classify each edge — an edge is sequence (a real ordering constraint — the dependent leaf consumes a specific output of the prereq) or parallel (a soft constraint — the prereq is "ready in that area" but no artifact is consumed). Drop soft constraints to unlock more parallelism; keep hard constraints because they gate correctness, not just schedule.
6. Compute the waves — repeatedly take the set of leaves whose prereqs are all in earlier waves; that's the next wave. Wave 1 = roots; Wave 2 = everything unblocked by Wave 1; etc. Anything inside one wave is parallel-safe; waves themselves are sequential.
7. Mark the critical path — the longest chain of sequence edges through the waves (sum of leaf estimates). The critical path sets the floor on total duration; parallel work on non-critical leaves can't shorten it, only widen the plan.
8. Surface the decision points — call out leaves whose prereqs aren't other leaves but external events (a stakeholder review, a deploy, a data feed). External prereqs are the plan's real schedule risk; track them separately from in-team work.
9. Check the model — three sanity checks before you ship the plan:
   • Hierarchy sound: every leaf has one parent phase and one owner; no orphan nodes.
   • Sequence minimal: every sequence edge traces to a consumed output; if you can't name the consumed artifact, the edge is parallel.
   • Cycles: none. A cycle means two leaves should be merged or a prereq is wrong.

Output format

Render the decomposition as three views on one artifact, not a flat list:

Goal: <one sentence outcome>

# 1. HIERARCHY (what decomposes into what)
Goal
├── Phase A: <name>
│   ├── Sub-goal A.1
│   │   ├── T1 <leaf>
│   │   └── T2 <leaf>
│   └── Sub-goal A.2
│       └── T3 <leaf>
└── Phase B: <name>
    └── T4 <leaf>

# 2. SEQUENCE (what must finish first)
T1 → T3 → T6 → T7 → T8        ← critical path (sum of estimates)

# 3. PARALLEL (what can run together)
Wave 1 (start now): T1, T2, T5
Wave 2 (after T1):    T3, T4
Wave 3 (after T2,T4,T5): T6
Wave 4 (after T1,T3,T6): T7  ← critical-path tail
Wave 5 (after T7):    T8

Then under it, a one-line note per leaf for inputs/outputs/estimate/owner. The hierarchy is for understanding scope, the sequence is the critical-path floor, the parallel waves are the dispatch artifact.

Example

Goal: ship a "user can export their data as CSV" feature.

Goal: user can export their data as CSV

# 1. HIERARCHY
Export-CSV
├── Backend
│   ├── T1 schema-mock CSV columns
│   ├── T3 column-mapping rules
│   └── T4 streaming serializer
├── Access
│   └── T5 access-policy filter
├── API
│   └── T2 pick download route (HTTP vs CLI)
├── Wiring
│   └── T6 wire route → serializer + filter
├── Tests
│   └── T7 contract tests
└── Docs
    └── T8 docs + release notes

# 2. SEQUENCE
T1 → T3 → T6 → T7 → T8         ← critical path

# 3. PARALLEL
Wave 1 (start now):     T1, T2, T5
Wave 2 (after T1):       T3, T4
Wave 3 (after T2,T4,T5): T6
Wave 4 (after T1,T3,T6): T7   ← critical-path tail
Wave 5 (after T7):       T8

Reading: T1/T2/T5 are roots and can start together; T3/T4 unblock after T1 and parallelize inside Wave 2; T6 and T7 sit on the critical path and gate everything else; T8 is a release-blocker on T7 alone.

Rules

• The graph, not the list, is the plan — a flat checklist hides hierarchy, hides parallel opportunities, and invents false sequencing.
• Every leaf has a parent, an owner, and an estimate — orphans, "TBD" owners, and missing estimates are leaves that will be re-decomposed under pressure, badly.
• Sequence edges trace to a consumed output — "we'd like it done first" is parallel until you name the artifact.
• Prereqs are edges, not vibes — if a prereq isn't actually consumed (no shared output, no shared resource, no shared decision), drop the edge and parallelize.
• Hierarchy is for scope, sequence is the floor, parallel is the dispatch — three views, one model.
• External prereqs are louder than internal ones — a leaf waiting on a stakeholder review is a leaf waiting on a calendar; mark it and time-box it.
• Cycles mean you've mis-modeled the work — back up and find the merge, not the workaround.
• Critical path is the floor, not the ceiling — parallel work doesn't shorten it; only re-sequencing or splitting a critical-path leaf does.

Related skills

• journey-driven-implementation — Decompose by user-journey steps when the goal is a feature; combine when the goal is also user-facing (journey first → then this skill's three-view plan).
• lean-implementation — Keep each leaf as small as the outcome allows; merge or delete leaves that don't serve the goal.
• loop-triage — When many goals land at once, decompose each one then sequence the resulting plans.
• choose-skill — Use this skill when the work breaks into subtasks that other library skills should run.