decompose-tasks

Decompose an Approved Plan

Turn a confirmed design into the smallest useful executable task graph. Do not modify production code or reopen settled technical decisions.

Preconditions

1. Read AGENTS.md, the approved plan, its source intent, and only the contracts needed to understand delivery boundaries.
2. Require the plan status to be approved with no material open technical decision.
3. Return to plan if decomposition exposes a missing or contradictory design.
4. Return to the source owner if it exposes a change to accepted behavior; use write-spec only when a durable product contract is required.

Build the graph

1. Map each non-trivial source item to one or more observable delivery outcomes.
2. Create vertical tasks that each produce one coherent, verifiable result.
3. Add enabling work only when a delivery task cannot safely absorb it.
4. Identify dependencies from contracts, data flow, migrations, shared state, and required validation—not from an assumed coding order.
5. Identify change-surface conflicts before marking tasks parallel.
6. Confirm every source item is covered and every task supports one or an explicit plan obligation.

Avoid tasks named only after layers such as "backend", "frontend", or "database". Split a task when it has multiple outcomes, independent failure modes, unrelated change surfaces, or cannot fit one focused agent session. Do not split work that must change atomically to remain correct.

Classify each task

Choose one primary type:

• feature: delivers observable behavior;
• bugfix: restores accepted behavior by correcting a defect;
• enabler: unlocks later delivery without standalone product behavior;
• migration: changes persisted data, contracts, or compatibility state;
• verification: provides independent evidence not owned by another task;
• operations: changes build, deployment, observability, or runtime controls;
• maintenance: improves internals without changing accepted behavior;
• documentation: updates durable user or engineering guidance.