/prototype

name: prototype
description: Render a proposed redesign of a page on the current website as a self-contained static HTML file, then iterate via the impeccable craft loop. Per-page, idempotent, stale-aware. Use when the user asks for a redesign prototype, a before/after comparison, a design preview, a page mockup, a visual diff of the redesign, or invokes `$stardust prototype` (`/stardust:prototype` in Claude Code).
license: Apache-2.0
compatibility: Requires Node 22+, Playwright with Chromium resolvable from the project, playwright-cli on PATH, and the impeccable skill (github.com/pbakaus/impeccable) installed alongside stardust.

stardust:prototype

For each `directed` page, render a **proposed redesign** as a self-contained static HTML file at `stardust/prototypes/<slug>-proposed.html`. Open the file in the browser; iterate via chat-driven impeccable commands ("make the hero bolder", "tighten the cup-note grid"). Mark `approved` once the user signs off in the conversation.

`prototype` is not a renderer of its own design — it composes the target spec written by `direct` (`PRODUCT.md`, `DESIGN.md`, `DESIGN.json`, `stardust/direction.md`) onto the page content captured by `extract` (`stardust/current/pages/<slug>.json`). Visual creativity is delegated to `$impeccable craft` and the iteration commands (`bolder`, `quieter`, `distill`, `polish`, `colorize`, `typeset`, `layout`, `adapt`, `animate`, `delight`, `overdrive`, `impeccable`).

Inputs

• `<slug>` — optional positional. Prototype just this page. Without

it, prototype every `directed` page that is not `stale`.

• `--all` — prototype every `directed` page including stale ones.
• `--prep` — optional. Run in **migrate-prep mode**: fill page-type

gaps (prototype one representative archetype per type) and, on approval, write canon back to `stardust/canon/` and `DESIGN.json.extensions.canon`. See § Prep mode below and `reference/canon-extraction.md`. Typically invoked via the `prepare-migration` orchestrator.

• `--canon-from <slug>` — optional. Override the default canon-

author (which is the first approved prototype, typically `home`). Used when a different page should establish the design canon.

• `--publish-sample <slug>` — submit the named slug to the

stardust showcase. Triggers the publish-sample sub-flow documented in `reference/publish-sample.md`: eligibility checks, file staging, PR creation against the upstream stardust repo. Requires `gh` installed and authenticated. The showcase is a visual demonstration, not a deployable site — placeholder content is allowed and recorded in the PR body's § Unsourced content section. Design-quality gates stay strict: refuses on unjustified anti-toolbox hits, `:root` token contract failure, data-attributes contract failure, or impeccable hard-rule violations. P0/P1 critique findings warn but don't refuse. The showcase publishes via GitHub Pages on merge.

• `--cinematic` — optional. Layer a cinematic motion register

on top of the static prototype. The register is read from `DESIGN.json.extensions.motion.register` (written by `direct`); if absent, the prototype phase picks one using the same heuristic per `reference/motion-registers.md` § Selection heuristic. Output filename is `<slug>-cinematic.html` (alongside the static `<slug>-proposed.html`, never replacing it). Triggers the cinematic gates in motion validation (`reference/motion-validation.md` § Pass 6).

• `--cinematic=<register>` — optional. Same as `--cinematic` but

forces a specific register (`arrival`, `kinetic-display`, `live-systems`, `editorial`, `kinetic-grid`). The override is recorded in `_provenance.motion.registerSource = "user-override"` so reviewers can spot when direction's heuristic was bypassed.

No opt-outs

`prototype` does not carry `--no-*` or `--skip-*` flags. The quality gates (critique, audit, mobile-adapt audit, anti-toolbox audit, content-sourcing scan) are the product — they're not optional. If a gate refuses a file, the remediation is to fix the file or override the gate by editing the file directly, not to pass a flag that silently lowers the bar. Manual chat overrides ("ship as-is", "accept the P1 findings") are still available; the agent records the override verbatim in `_provenance` so downstream consumers see the explicit acknowledgement.

Setup

0. **Playwright re-probe (mandatory first step).** `--no-save` playwright installs from earlier phases are pruned by any later real `npm i` (extract SKILL.md § Setup → `--no-save` installs are ephemeral). Before any rendering step, probe `node -e "import('playwright').then(()=>process.exit(0))"` from the project root and re-install (`npm i -D playwright --no-save --legacy-peer-deps`) on failure. 1. Run the master skill's setup (`skills/stardust/SKILL.md` § Setup). 2. Verify `stardust/state.json` exists and contains at least one `directed` page. If not, recommend `$stardust direct` and stop. 3. Verify the project-root `DESIGN.md` and `DESIGN.json` exist. If not, the direction was not fully authored — recommend `$stardust direct` and stop. 4. Verify `stardust/direction.md` has an active (not pending) direction. Pending directions block prototype. 5. **Validate provenance on every page in scope.** Call `validateProvenance(page)` per `skills/stardust/reference/state-machine.md` § Provenance validation for every page that this run will render (the single `<slug>` argument when present, otherwise every non-stale `directed`/`prototyped`/`approved` page). Abort with the helper's error when any page lacks live-render evidence — re-running `prototype` against a synthesized page record silently propagates the synthesis into the rendered prototype. Surface `Provenance OK on N pages` once the check passes. 6. Read `stardust/current/DESIGN.md` (the descriptive snapshot of the existing site, used as a fallback reference during render when th