/task-decomposer

name: task-decomposer
description: 'Produces phased task boards from feature requests: dependency-mapped work items, parallelization flags, risk flags, edge cases, test matrices. Triggers on: "decompose this feature", "task breakdown with dependencies", "phased implementation plan", "work breakdown structure". NOT for effort estimates, use estimate-calibrator.'
metadata:
  version: 1.1.1
  category: development
  tags: [task-breakdown, dependencies, planning, phased]
  difficulty: intermediate
  phase: plan

Task Decomposer

Transforms ambiguous feature requests into concrete, implementable task sequences: identifies acceptance criteria, decomposes into tracer-bullet vertical slices with effort sizing, maps dependencies and parallelization, enumerates edge cases, plans testing, labels HITL/AFK readiness, and flags risks — producing a ready-to-execute task board.

> **When to use this skill vs native decomposition:** The base model decomposes features > well in an ad-hoc format. Use this skill specifically when you need the structured output: > phased task tables with dependency mapping, parallelization flags, risk flags, and > integrated test strategy. If you just need a quick list of steps, ask directly without > invoking this skill.

Reference Files

| File | Contents | Load When | | -------------------------------------- | --------------------------------------------------------------- | ------------------------------- | | `references/decomposition-patterns.md` | Feature → task decomposition strategies, granularity guidelines | Always | | `references/edge-case-checklist.md` | Common edge case categories by domain (web, API, data, CLI) | Edge case identification needed | | `references/dependency-mapping.md` | Dependency graph construction, critical path identification | Multi-task breakdown | | `references/sizing-guide.md` | Effort estimation guidance (S/M/L), complexity indicators | Effort sizing needed |

Prerequisites

• Feature description or requirements (can be vague — the skill handles ambiguity)
• Project context (tech stack, existing architecture, team size)

Project Context

Before decomposing, check for repo-local agent context:

• `docs/agents/domain.md` for `CONTEXT.md`, `CONTEXT-MAP.md`, and ADR lookup rules
• `docs/agents/triage-labels.md` for readiness labels when tasks become issues
• `CONTEXT.md` or relevant context-local glossary for task titles and acceptance criteria
• `.out-of-scope/` for durable rejections that may affect scope

Continue if these files are absent, but state that the plan is using inferred vocabulary.

Workflow

Phase 1: Understand the Feature

1. **Extract the user-facing goal** — What does this feature enable the user to do? If unclear, state assumptions explicitly. 2. **Define acceptance criteria** — What must be true for this feature to be "done"? Express as testable statements: "User can X", "System does Y when Z." 3. **Identify non-functional requirements** — Performance, security, accessibility, backwards compatibility constraints. 4. **Clarify scope boundaries** — What is explicitly out of scope? State this to prevent scope creep during implementation.

Phase 2: Decompose into Vertical Slices

Break the feature into tracer-bullet slices first, then split oversized slices into tasks. Each slice should deliver a narrow but complete path through the affected layers. Avoid horizontal breakdowns where one issue only creates schema, another only creates API, and another only creates UI unless the work is pure infrastructure.

| Granularity | Size | Example | | ----------- | ---------------------------------------------- | ---------------------------- | | Too coarse | "Build the search feature" | Not actionable | | Right level | "Exact-match product search returns results end-to-end" | Single PR, testable | | Too fine | "Import the search library" | Not independently meaningful |

**Right granularity test:** Each task should be completable in a single PR, testable in isolation, and deliverable independently. A completed vertical slice should be demoable or verifiable without waiting for unrelated slices.

Group tasks into phases:

| Phase | Purpose | Contains | | ----- | ------- | -------- | | Setup | Shared contracts or migrations that unblock slices | Types, schemas, fixtures | | Slice 1 | First end-to-end behavior | Minimal data, logic, API, UI/CLI path | | Slice N | Incremental capability | One user-visible behavior or operational capability | | Hardening | Cross-slice edge cases and quality gates | Performance, security, docs, cleanup |

Label each slice:

• **AFK** — an agent can implement it from the issue brief with no further human context.
• **HITL** — requires human judgment, external access, product approval, design review, or release authority.

Phase 3: Identify Edge Cases

For each task, enumerate edge cases:

1. **Input boundaries** — Empty, null, maximum size, special characters 2. **State transitions** — Concurrent modification, interrupted operations 3. **Error conditions** — Network failures, invalid data, permission denied 4. **Backwards compatibility** — Existing data, existing API consumers

Phase 4: Plan Testing

For each task, identify what to test:

| Test Level | What to Test | Who Writes | | ----------- | ------------------------------------- | ----------------------- | | Unit | Individual functions, pure logic | During implementation | | Integration | Component interactions, API endpoints | After integration phase | | Manual | User flows, visual correctness | After polish phase |

Phase 5: Map