slice

§ 01 · purpose

Purpose

Cuts a feature into the smallest set of *independently designable* vertical slices (scope boundaries only, no architecture decisions) so that design-slice can fill each one in parallel. Also runs in re-slice mode with full structural authority (split an epic, break a cycle, redistribute coverage) when the design-readiness gate fails the map. It takes over there because a surgical reviser cannot split a slice.

§ 02 · when to use

When to use it

• A research artifact exists and the feature needs decomposition before a per-slice design fanout.
• Dispatched by the build pipeline between research and design-slice.
• Re-slice mode (--slices … --slice-verdicts …) when the design-readiness gate failed the map and the fix is structural, not surgical.
• Prefer design when decomposition and design can fold into one interactive pass. slice deliberately stops at scope boundaries.

§ 03 · inputs

Inputs

research artifact

Read FULLY, plus the key source files it cites. Every slice's Draws on: must cite a real file:line from it. A missing or non-research argument is a dispatch error, not a prompt to improvise.

--slices

Selects re-slice mode (non-interactive, no confirmation).

--slice-verdicts

Failing findings are joint constraints. A re-cut for one must not regress a dimension that was passing.

§ 04 · outputs

Outputs

§ 05 · key steps

Key steps

1. 01 Read the research and its cited sources fully Why: The research is the cut's grounding, and design-slice does NO discovery downstream. An under-cited Draws on: doesn't make a slice smaller, it starves the design pass.
2. 02 Enumerate coverage units before cutting Why: Freezing the brief's observable outcomes as ID'd units (c1, c2, …) up-front lets a program verify coverage conservation with 0 LLM calls. A later re-cut may redistribute units across slices but can never quietly drop one to shrink a slice.
3. 03 Cut vertical, independent, right-sized slices Why: Horizontal layers ("all the types") are valuable only once combined. Each slice must therefore be a user- or system-meaningful capability resolving to one coherent architecture decision, the exact bar the design-readiness gate later judges.
4. 04 Resolve genuine decomposition forks with the developer Why: A fork like "combine auth + session, or split them?" changes every downstream design, so it is asked one at a time with concrete options rather than guessed.
5. 05 Confirm the decomposition once, then write Why: A single approve/adjust question before writing is far cheaper than moving a slice boundary after N parallel designs have built on it.
6. 06 In re-slice mode, re-cut structurally from the verdicts Why: Splitting an epic, inverting a dependency edge, or renumbering exceeds what amend may touch. So the pipeline re-dispatches slice itself, with the verdict feedback as the instruction and the coverage: array carried forward verbatim.

§ 06 · related skills

Related skills