Task Decomposition
Break an epic or fuzzy feature into INVEST-sized, dependency-aware slices so a solo builder can estimate, parallelize, and ship without scope creep.
Overview
Task Decomposition is an agent skill most often used in Validate (also Build, Operate) that breaks overwhelming epics into right-sized, dependency-aware tasks using cognitive limits and INVEST-style slicing.
Install
npx skills add https://github.com/jwynia/agent-skills --skill task-decompositionWhat is this skill?
- Diagnostic workflow for tasks that feel too big, blocked, or creeping in scope
- Cognitive-limit quick reference table to size tasks for complete understanding
- INVEST, vertical slice, spike, and dependency guidance for parallel-safe work
- Explicit stop rules: skip when work is already small; defer architecture to system-design
- Integrates with github-agile for tracking decomposed work items
- Claims properly decomposed tasks achieve 3x higher completion rates
- Claims 60% fewer defects when tasks respect decomposition guidance
- Includes a cognitive-limits quick reference table with threshold columns
Adoption & trust: 525 installs on skills.sh; 92 GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You face an epic or fuzzy task that feels impossible to estimate, keeps growing, or is blocked by unclear dependencies and you do not know where to start.
Who is it for?
Solo builders staring at a too-large story, epic, or refactor who need slices before asking an agent to implement.
Skip if: Work that is already small and well-defined, active implementation sessions, or architecture decisions that need system-design instead.
When should I use this skill?
User says task too big, can't estimate, overwhelmed by scope, where do I start, epic needs breakdown, or has dependency problems.
What do I get? / Deliverables
You get a bounded backlog of understandable, value-sized units with clearer dependencies so estimation, parallel work, and tracking can proceed without treating decomposition as busywork.
- Decomposed task list sized for cognitive limits and independence
- Clear boundaries and dependency notes for parallel or sequenced work
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Canonical shelf is Validate/scope because the skill triggers when work is still too big to commit—before full Build—matching “can’t estimate,” “where do I start,” and epic breakdown. Scope subphase is where solo builders define what fits in the next increment; decomposition turns overwhelming scope into bounded units with clear dependencies.
Where it fits
Split a landing-page plus auth epic into vertical slices before committing to a two-week build.
Re-decompose a growing “user dashboard” story so parallel agent tasks do not block on shared files.
Order release checklist items into independent chunks with explicit dependencies before cutover.
Break a production incident remediation into spike vs fix tasks instead of one vague “fix prod” ticket.
How it compares
Use instead of dumping an entire epic into one agent prompt without sizing or dependency order.
Common Questions / FAQ
Who is task-decomposition for?
Solo and indie developers who own scoping and delivery and need a structured way to split big work before estimation or agent implementation.
When should I use task-decomposition?
Use it in Validate when scoping an MVP or epic, in Build/PM when a backlog item balloons, and in Operate when production fixes need ordered sub-tasks—especially when you say the task is too big, you cannot estimate, or dependencies block you.
Is task-decomposition safe to install?
It is assistive planning content with no required shell or network tools in the skill itself; review the Security Audits panel on this Prism page before trusting any third-party skill package.
SKILL.md
READMESKILL.md - Task Decomposition
# Task Decomposition Diagnostic Transform overwhelming development tasks into manageable units by respecting cognitive limits, creating clear boundaries, and enabling parallel work. Tasks properly decomposed achieve 3x higher completion rates and 60% fewer defects. ## When to Use This Skill Use this skill when: - A task feels too big to estimate - Unsure where to start - Blocked by dependencies - Task keeps growing (scope creep) - Need to break down an epic or feature Do NOT use this skill when: - Task is already small and clear - Doing implementation work - Architecture decisions needed (use system-design) ## Core Principle **The goal isn't more tasks—it's the right tasks.** Tasks small enough to understand completely, large enough to deliver value, independent enough to avoid blocking. ## Quick Reference: Cognitive Limits | Limit | Threshold | Implication | |-------|-----------|-------------| | Working memory | 7±2 items | Max concepts per task | | Context switch recovery | 23 minutes | Minimize task switching | | Files examined | 15-20 max | Bound task scope | | Days before completion drops | 2-3 days | Keep tasks under this | ## Task Duration Success Rates | Duration | Completion Rate | |----------|-----------------| | < 2 hours | 95% | | 2-4 hours | 90% | | 4-8 hours (1 day) | 80% | | 2-3 days | 60% | | 1 week | 35% | | > 2 weeks | <10% | ## Diagnostic States ### TD1: Too Big to Understand **Symptoms:** Estimates range wildly, can't hold all requirements in mind, more than 7 concepts to track **Interventions:** - Apply INVEST criteria: Independent, Negotiable, Valuable, Estimable, Small, Testable - Use vertical slicing (each slice is independently deployable) - Apply walking skeleton (minimal end-to-end first) ### TD2: No Clear Entry Point **Symptoms:** Multiple valid starting points, paralysis, everything seems connected **Interventions:** - Front-load risk: start with highest-uncertainty items - Tracer bullet: minimal proof of concept - Find the walking skeleton: thinnest slice through all layers ### TD3: Dependency Problems **Symptoms:** "Blocked on X", diamond dependencies, coordination overhead **Interventions:** - Interface contracts: define API, mock while implementing - Feature flags: deploy independently, enable when ready - Branch by abstraction: create layer, swap implementations ### TD4: No Clear Done Criteria **Symptoms:** "Almost done" forever, no way to verify completion **Interventions:** - Define acceptance criteria (Given/When/Then) - Time-box to force prioritization - Define explicit out-of-scope items ### TD5: Scope Creep **Symptoms:** Task keeps growing, "while we're here" additions **Interventions:** - Freeze scope, spawn new tasks for additions - Define minimum viable version - Ship smallest version that solves the problem ### TD6: Need Spike First **Symptoms:** Estimate variance > 4x, new technology, multiple approaches **Interventions:** - Time-boxed spike (8 hours max) - Deliverables: options, POC, trade-offs, revised estimate - Spike then implement pattern ## Decomposition Patterns ### Vertical Slicing (Preferred for Features) ``` Feature: User Profile Management Slice 1: View basic profile (4h) - UI: Profile display - API: GET /profile - DB: Read profile Slice 2: Edit profile name (6h) - UI: Edit dialog - API: PATCH /profile/name - DB: Update profile Each slice i