# Decompose

> Breaks one epic or feature into day-sized (or smaller) work items -- a fast-path companion to Pillar 4 (Increase Speed). Use when planning a single feature or epic, independent of running a full speed/throughput analysis.

- Skill: `clearmeasurelabs/decompose` (Agent Skill)
- Install (CLI): `npx skillmds@latest add clearmeasurelabs/decompose`
- Raw SKILL.md: https://api.skillmd.com/api/skills/clearmeasurelabs/decompose/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: ClearMeasureLabs (https://skillmd.com/u/clearmeasurelabs)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/clearmeasurelabs/decompose

---


# /decompose -- Work Item Decomposition

**Fast-path companion to Pillar 4 (Increase Speed).** Breaks one epic or
feature into work items sized at roughly a day of effort or less, without
running a full `/speed` throughput analysis. The book's guidance: standardize
decomposition into small, countable units so work can be forecasted, not
estimated.

## When to invoke

- Planning a single feature or epic before it enters a sprint/backlog
- An item has sat "in progress" for multiple days with no sub-tasks -- break it down now
- Before estimating a feature -- decompose first, then let counted throughput do the forecasting (see `/speed`)

## What it checks

1. **Current shape** -- is the feature/epic currently one large ticket, or already split? How big is each piece today (days-open as a proxy if points aren't tracked)?
2. **Natural seams** -- where does the work split along independently shippable, independently testable lines (e.g., by layer, by user-facing slice, by data migration vs. behavior change)?
3. **Sequencing** -- which sub-items unblock others, and which can ship in parallel?
4. **Cuttable scope** -- is there a "least amount of work to accomplish the outcome" version, with clearly-optional pieces flagged separately (ties to Speed's "waste" check)?

## Inputs

- **The feature/epic itself** -- the ticket description, a design doc, or the user's plain-language description of what needs to happen
- **Existing size signal, if any** -- similar past items' actual days-to-close, to sanity-check that each proposed sub-item is roughly a day or less
- If the feature is too vague to decompose (no acceptance criteria, no clear "done"), say so -- that's a Clarity gap (`/clarity`), not a decomposition problem, and forcing a breakdown on a vague ask just produces vague sub-tasks

## Example output

> **Decomposition -- "Bulk export" feature, Atlas API**
>
> **Current shape:** One epic, no sub-tasks, currently estimated "3-5 days" -- the kind of item that historically averages 6 days open per `/speed`'s decomposition check.
>
> **Proposed sub-items (day-sized or less):**
>
> 1. Add `POST /exports` endpoint that accepts a format param and returns a job ID (backend only, no UI) -- ~1 day
> 2. Implement CSV generation from existing query, write to blob storage -- ~1 day
> 3. Add export-status polling endpoint + minimal UI to trigger/download -- ~1 day
> 4. *(Optional, cut unless requested)* JSON/XML output formats -- usage logs show CSV is the only format ever requested; ship CSV first, revisit only if asked
>
> **Sequencing:** 1 blocks 2 and 3; 2 and 3 can run in parallel once 1 lands. Item 4 is independent and can be dropped without blocking anything.
>
> **Cuttable scope:** Item 4 -- estimated 2-3 days for formats with no recorded demand. Recommend cutting it from this pass entirely.
>
> **Recommended next step:** Ship items 1-3 as separate tickets this sprint; track item 4 in the backlog as "cut, revisit if requested" rather than silently dropping it.

## Reference

See [../../docs/FIVE_PILLARS.md](../../docs/FIVE_PILLARS.md#pillar-4-increase-speed) and [../speed/SKILL.md](../speed/SKILL.md) for the full flow/throughput analysis this feeds into.