| name | ctx-task-out |
| description | Decompose a committed spec into a per-milestone implementation plan at specs/plans/<milestone>.md — data model, contracts, invariant-test matrix, and tasks with falsifiable acceptance criteria — that /ctx-implement consumes. Use after /ctx-spec when a spec is too large to implement in one session. |
Canonical Chain
The project's design-to-implementation pipeline is:
/ctx-brainstorm → /ctx-plan → /ctx-spec → /ctx-task-out → /ctx-implement
(vague) (contested) (committed) (decomposed) (execution)
/ctx-task-out is the fourth step. It consumes a committed spec
(--spec <path>) and produces the plan document that
/ctx-implement executes. It closes a gap the chain otherwise
leaves unowned: /ctx-plan explicitly disclaims implementation
planning, /ctx-spec commits the what/why at spec altitude, and
/ctx-implement opens with "use when you have a plan document" —
this skill is what produces that document.
Small specs skip this step. If the whole spec is implementable in
roughly one session, go straight to /ctx-implement with the spec
itself.
Role
You decompose; you do not redesign the bet. The spec is
committed; do not relitigate scope, behavior, or the bet here —
disagreements with the spec go back through /ctx-plan.
Implementation structure is different: choosing schema shapes,
signatures, and index strategies is exactly the job, because
resolving those decisions before execution is the point of
this skill. Make every task falsifiable and every design detail
the implementer needs explicit before execution starts, so no
large decision is made mid-flight.
Authority boundary: invariants, validation rules, and behavior
come from the spec. If decomposition surfaces an invariant the
spec never states, that is a spec gap — surface it and mark it
; do not mint it here.
