§ reference · skill

design-slice

Designs one vertical slice from a slice map in isolation, writing its architecture decisions, file map, key interfaces, and success criteria to `.rpiv/artifacts/designs/`.

arguments <slices-path> Slice N: <title> [--upstream <design-path>]...

§ 01 · purpose

Purpose

The fanout unit of the build pipeline's design stage: N instances run in parallel, one per slice, each designing *only its own slice* against the footing the slice map cites. It does no discovery. The slice's Draws on: file:lines are the entire reading list. That is exactly why the design-readiness gate demands fully-cited slices upstream.

§ 02 · when to use

When to use it

  • Dispatched once per slice by the build pipeline's design fanout, after the slice map clears its gate.
  • A dependency's design exists and this slice must build against its published contract (--upstream).
  • Not standalone. The per-slice designs only become a plan after the design review and synthesize.
  • Prefer design when the work was never sliced. This skill assumes the decomposition is already cut and refuses to redraw it.

§ 03 · inputs

Inputs

Name Required Source
slice map + slice name yes <slices-path> Slice N: <title> (a map under .rpiv/artifacts/slices/ plus the single slice to design)
--upstream no A direct dependency's design doc under .rpiv/artifacts/designs/ (repeatable)
slice map + slice name
A missing path or unparseable Slice N is a dispatch error. The slice's Out of scope fence is binding.
--upstream
Injected by the fanout once the dependency completes. Only its ## Key Interfaces and ## Notes / Deferred are read. Transitive dependencies are synthesize's problem.

§ 04 · outputs

Outputs

Artifact Path Format
Per-slice design doc .rpiv/artifacts/designs/ markdown (Approach, File Map, Key Interfaces, Integration Points, Success Criteria, Notes / Deferred)

§ 05 · key steps

Key steps

  1. Locate the one ## Slice N section and honor its fences Why: Sibling lanes run concurrently on the other slices. Respecting Out of scope is what keeps N parallel designs from colliding on the same decision.
  2. Read the slice's cited footing fully, and nothing more Why: This skill runs no discovery or analysis subagents by design; the slice map's Draws on: citations are the whole evidence base, keeping each lane bounded and cheap.
  3. Consume upstream ## Key Interfaces as fixed contracts Why: A shared contract has exactly one owning slice. Redesigning a dependency's published shape would fork the truth that synthesize later has to reconcile by coin-flip.
  4. Decide the slice's shape as code shape, not implementation Why: Interfaces, file map, and decisions are what synthesize merges and the grade panel judges. Actual code is written later, per phase, by elaborate and applied by implement.
  5. Ask the developer only on a genuine blocking fork Why: An undecided upstream contract or a real design fork cannot be settled from the inputs. But approval of the finished design belongs to the consolidated design review and the grade panel, not to per-slice prompts.
  6. Write the doc with status: ready Why: There is no self-review. The design review and the plan gate own validation, so the lane ends the moment the artifact lands.

§ 06 · related skills

upstream slice
downstream design-review