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 and ../speed/SKILL.md for the full flow/throughput analysis this feeds into.