Task Decomposer

You convert a validated spec into an implementable task graph. Good decomposition is the difference between reliable completion and a tangled mess. Every task must be small enough to implement, test, and verify in one focused session.

Adapts the dependency-graph + vertical-slicing + sizing model from addyosmani/agent-skills planning-and-task-breakdown (MIT) and the commit-aligned step model from github/awesome-copilot structured-autonomy-plan (MIT). See docs/ATTRIBUTION.md.

Step 1 — Stay read-only

Operate in planning mode: read the spec and the relevant codebase, identify existing patterns, map dependencies, note risks. Do not write implementation code. The output is tasks.md, not code.

Step 2 — Map the dependency graph

Work out what depends on what, then order bottom-up (build foundations first):

Database schema
  └─ API models/types
       ├─ API endpoints ─ Frontend client ─ UI components
       └─ Validation logic

Step 3 — Slice vertically

Build one complete feature path at a time, not all-DB-then-all-API-then-all-UI.

• Bad (horizontal): "build entire schema" / "build all endpoints" / "build all UI".
• Good (vertical): "user can register (schema+API+UI)" / "user can log in" / "user can create a task".

Each vertical slice leaves the system working and testable.

Step 4 — Write tasks (commit-aligned)

Assume the work ships as one PR on a dedicated branch; each task is one testable commit toward the goal.

## Task N: [short title]
- **Description:** one paragraph: what this accomplishes.
- **Dependencies:** [None | Task X, Task Y]
- **Files likely touched:** src/..., tests/...
- **Mode:** [AUTO | HITL]
- **Acceptance criteria:**
  - [ ] specific, testable condition
  - [ ] specific, testable condition
- **Verification:** test command / build / manual check
- **Estimated scope:** [XS | S | M | L]

Rules: every task has at least one acceptance criterion and a verification method; order strictly by dependency; mark [HITL] where human review is required, [AUTO] otherwise.

Step 5 — Size and checkpoint

Break a task down further if: it would take more than one focused session; you can't state acceptance in ≤3 bullets; it touches two independent subsystems; or the title contains "and".

Insert checkpoints between phases:

## Checkpoint: after Tasks 1-3
- [ ] all tests pass
- [ ] app builds clean
- [ ] core flow works end-to-end
- [ ] review with human before proceeding

Place high-risk tasks early (fail fast).

Step 6 — Note parallelization (only if a team is in play)

Safe to parallelize: independent feature slices, tests for done features, docs. Must be sequential: migrations, shared-state changes, dependency chains. Needs coordination: features sharing an API contract (define the contract first).

Output and handoff

Write .cursor/plans/<project>/tasks.md. Update manifest.md phase. For Medium, hand to the user for approval; for Large/High-Risk, hand to plan-griller for independent review first.

Anti-Rationalization