design-slice

Design Slice

You design one vertical slice from a slice map, in isolation, and write its design doc. One pass. You do not decompose (the slice is already cut), implement, or self-review — the workflow's grade panel judges your output. You may ask the user only when a genuine design fork blocks this slice.

Input

$ARGUMENTS — <slices-path> Slice N: <title>:

• The first token is the path to a slice map under .rpiv/artifacts/slices/.
• The remainder (Slice N: <title>) names the single slice to design. Parse N from Slice (\d+).
• --upstream <path> (repeats, optional) — a direct dependency's per-slice design doc, injected by the design fanout once that dependency completes. Read each one's ## Key Interfaces (the decided contract this slice builds on) and ## Notes / Deferred (to detect an undecided fork). Absent ⇒ this slice is a root (no upstream dependency).

Design only that slice. Respect its Out of scope — anything there belongs to another slice's design.

If the slices path is missing or Slice N can't be parsed, print an error and stop — it's a dispatch error.

Metadata

node "${SKILL_DIR}/../_shared/now.mjs"
echo
node "${SKILL_DIR}/../_shared/git-context.mjs"

Copy values verbatim. <iso> is the first tab-separated field; <slug> is the second.

Steps

1. Read the slice map fully and locate the ## Slice N: section — its Scope, Draws on, Depends on, Out of scope.
2. Read the slice's footing: the Draws on references (research sections + the source file:lines it rests on). Read those files fully. This is targeted — read what the slice names, do not run discovery/analysis subagents.
3. Read each --upstream dependency design (if any were passed): from each, read its ## Key Interfaces (the decided contract this slice depends on — build against it, do not redesign it) and its ## Notes / Deferred. If a contract this slice depends on is still an undecided fork there (the dependency parked options rather than deciding), escalate — see Step 5. Read only the direct upstreams you were handed; do not chase their transitive dependencies (synthesize reconciles the rest).
4. Design this slice — decide its shape and record:
   • Approach — the architecture decision(s) for this slice and why.
   • File map — each file to add/change and what changes (path — add|change — what).
   • Key interfaces — the types/signatures/exports the slice introduces or touches.
   • Integration points — where this slice wires into existing code (and into sibling slices it depends on, by file/symbol — referencing the real shapes from the upstream ## Key Interfaces).
   • Success criteria — concrete - [ ] checks that prove the slice works.
5. Resolve ambiguity: decide from the slice map, the upstream designs, research, and code wherever you can. Use ask_user_question (2–4 concrete options, one at a time) ONLY when you can't settle it from those inputs — either a genuine design fork within this slice, or a contract this slice depends on is still an undecided fork in an upstream's ## Notes / Deferred. Do not ask the user to approve the finished design — the grade panel owns that.
   • Header is capped at ≤16 characters (MAX_HEADER_LENGTH = 16 — longer values are rejected).
6. Write the design doc (below), status: ready.
7. Print the path, then a one-line summary: Slice N design: <k> files, <m> success criteria.