§ reference · skill

design-review

Runs the pipeline's one human design gate, presenting every per-slice design as a single consolidated summary the developer accepts or adjusts before synthesis.

arguments --designs <design-path> [--designs <design-path> ...] --slices <slices-path>

§ 01 · purpose

Purpose

The fan-in point where the developer signs off on the proposed shape (data types, key interfaces, file map, scope) across *all* slices at once. Adjustments are applied surgically in place, and a changed contract is cascaded to its transitive dependents. synthesize then merges designs that already agree with the developer's call.

§ 02 · when to use

When to use it

Dispatched once by the pipeline between the design fanout and synthesize. Not standalone.
The interface surface across slices needs human sign-off before it hardens into a plan.
Prefer the re-slice path when an adjustment demands a fundamentally different approach. The skill's own escape hatch stops rather than fake a reconcile, because structural authority lives upstream in slice.

§ 03 · inputs

Inputs

Name	Required	Source
`--designs`	yes	Per-slice design docs under `.rpiv/artifacts/designs/` (repeatable)
`--slices`	yes	The slice map under `.rpiv/artifacts/slices/` the designs were cut from

--designs: Frontmatter slice_n, slice_title, depends_on build the dependency graph.
--slices: Authoritative for deps, Scope, and Out-of-scope fences.

§ 04 · outputs

Outputs

Artifact	Path	Format
The accepted design docs, re-emitted in place (edited ones with `last_updated` bumped)	`.rpiv/artifacts/designs/`	markdown, same files, same paths; no new artifact is created

§ 05 · key steps

Key steps

Read every design and build the dependency graph Why: Cascading a contract change requires knowing each slice's transitive dependents up-front. The graph comes from the designs' depends_on, cross-checked against the slice map.
Present one consolidated, dependency-ordered summary Why: The developer reviews the whole proposed shape once, led by data types and interfaces (the contract being signed). Per-slice approval is exactly what the design fanout forbids, so it is never reintroduced here.
Ask accept-or-adjust, and loop until accepted Why: This is the single human design gate in the build pipeline. Everything after it (synthesis, grading, elaboration) runs on machine gates, so ambiguity must not survive past this point.
Classify each adjustment as contract-local or contract-changing Why: An internal approach tweak touches one doc; a change to published ## Key Interfaces leaves every dependent stale. Without the cascade, the developer's choice silently loses the merge in synthesize.
Apply surgically, cascade, re-present Why: Only what the developer cited is touched (the amend discipline). Dependents get their references patched plus a one-line note in ## Notes / Deferred, and the updated summary comes back for re-approval. The loop is internal to the skill.
Stop honestly when a patch cannot reconcile Why: A dependent that needs a different approach, not a renamed contract, means the cut itself is wrong. That is re-slice territory, and faking the reconcile would corrupt the plan downstream.

§ 06 · related skills

upstream design-slice

downstream synthesize