prototype · adobe — Claude Code skill: redesign prototype as static HTML
Renders a proposed page redesign into one self-contained static HTML file you can open in a browser and iterate on from chat.
npx skills add adobe/skills --skill prototype -a claude-codeWhat prototype does
The skill takes the target design written by direct (PRODUCT.md, DESIGN.md, DESIGN.json, stardust/direction.md) and composes it onto page content captured by extract (stardust/current/pages/<slug>.json). Output lands at stardust/prototypes/<slug>-proposed.html. It does not draw the design itself: the creative work goes to $impeccable craft, and revisions run through bolder, quieter, distill, polish, colorize, typeset, layout, adapt, animate, delight, overdrive.
With no argument it prototypes every directed page that is not stale. --all includes stale ones, --cinematic writes a <slug>-cinematic.html next to the static file, and --publish-sample <slug> submits a page to the stardust showcase as a pull request. The --prep mode fills page-type gaps and writes canon back to stardust/canon/.
Setup is checked before anything renders. You need Node 22+, Playwright with Chromium resolvable from the project, playwright-cli on PATH, and the impeccable skill installed alongside. Playwright installs made with --no-save in earlier phases get pruned by any later real npm i, so the skill re-probes the playwright import and reinstalls on failure. There are no --no-* or --skip-* flags here: the quality gates are part of the process, and when a gate refuses a file you fix the file rather than lower the bar.
What it helps with
- see how a page redesign looks before touching the code
- put the current page and the proposed one side by side
- build a page mockup and get it signed off in chat
- prototype one representative page per type while prepping a migration
- submit a finished prototype to the stardust showcase via pull request
Example prompts for the agent
- /stardust:prototype home
- $stardust prototype --all
- $stardust prototype home --cinematic
How to install prototype
1Skills CLI (Vercel)
npx skills add adobe/skills --skill prototype -a claude-code2Manually: put the files in place
~/.claude/skills/prototype/SKILL.mdCopy the whole skill folder; for one project use .claude/skills/prototype/
1Skills CLI (Vercel)
npx skills add adobe/skills --skill prototype -a codex2Manually: put the files in place
.agents/skills/prototype/SKILL.mdFor all projects use ~/.agents/skills/
1Skills CLI (Vercel)
npx skills add adobe/skills --skill prototype -a cursor2Manually: put the files in place
.cursor/skills/prototype/SKILL.mdCursor also reads .agents/skills/ and .claude/skills/
1GitHub CLI
gh skill install adobe/skills prototype2Manually: put the files in place
.github/skills/prototype/SKILL.md1Skills CLI (Vercel)
npx skills add adobe/skills --skill prototype -a gemini-cli2Platform CLI
gemini skills install https://github.com/adobe/skills --path plugins/stardust/skills/prototypeManually: put the files in place
.devin/skills/prototype/SKILL.mdThe legacy .windsurf/skills/ path still works
Skills CLI (Vercel)
npx skills add adobe/skills --skill prototype -a opencodeClaude.ai
Zip the folder and upload it in Settings → Capabilities → Skills
Step by step, with commands for each platform: How to install skills in Claude Code: five ways
Questions about prototype
How do I install prototype in Claude?
Run npx skills add adobe/skills --skill prototype -a claude-code. The skill file then sits at ~/.claude/skills/prototype/SKILL.md.
What does prototype do?
It renders a proposed page redesign as a self-contained static HTML file at stardust/prototypes/<slug>-proposed.html and lets you iterate on it with impeccable commands from chat. It works per page and flags stale prototypes.
What does prototype need to run?
Node 22+, Playwright with Chromium resolvable from the project, playwright-cli on PATH, and the impeccable skill installed alongside. It also needs the direction files from direct and the captured pages from extract.
Source text
SKILL.md · Apache-2.0
---
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 the
proposed file needs to mirror an aspect of the captured surface).
## Delegation mechanic
`prototype` does **not** author `<slug>-proposed.html` directly. The
heavy creative lift is delegated to `$impeccable craft`, and (when
needed) the structural plan to `$impeccable shape`. Spelling out the
mechanic matters because the carve-out documented in
`skills/stardust/reference/artifact-map.md` (where stardust authors
`PRODUCT.md`, `DESIGN.md`, `DESIGN.json`, `current/PRODUCT.md`,
`current/DESIGN.md` directly, treating impeccable's references as
*format specs*, not runtime commands) is **load-bearing for those
five files only**. It does NOT extend to:
- `stardust/prototypes/<slug>-proposed.html` — must be authored by
`$impeccable craft`, not by stardust direct authoring.
- Iteration on the proposed file — must be driven through a
chat-driven invocation of an explicit impeccable command (per
the iteration paths section).
- Structural planning when a page is complex enough to need it —
`$impeccable shape`.
The proximate cause of past content fabrication was the agent
over-generalizing the direct-authoring carve-out to the proposed
HTML. Don't.
### Invoking impeccable
Impeccable is a skill, not a CLI. Invoke it through the harness's
skill-invocation tool, passing the sub-command and its args as the
skill's argument string, mirroring the slash-command form. In Claude
Code the plugin namespaces it as `impeccable:impeccable`:
```
Skill {
skill: "impeccable:impeccable",
args: "craft <feature-description>"
}
```
In GitHub Copilot and other harnesses that flatten plugin skills the
skill is named `impeccable` and takes the same argument string
(`craft <feature-description>`). Every Claude Code `Skill { ... }`
example in this skill translates the same way.
Sub-commands referenced from this skill are all routed through the
same skill: `craft`, `shape`, plus the iteration commands
(`bolder`, `quieter`, `distill`, `polish`, `colorize`, `typeset`,
`layout`, `adapt`, `animate`, `delight`, `overdrive`, `impeccable`).
When impeccable is **not** available (CLI-only environments,
plugin uninstalled, sandbox without skill access), stop and tell
the user impeccable is required for prototype rendering. Recommend
installing the impeccable plugin. Do not fall back to direct
authoring of `<slug>-proposed.html` — the validation contract
craft enforces (anti-toolbox audit, divergence rules, type ratios,
content sourcing hierarchy) is not reproducible by direct
authoring, and falling back silently ships unverified output.
Stardust's job inside Phase 2 is therefore:
- Compose the inputs craft needs (page content from
`current/pages/<slug>.json`, target spec from `DESIGN.md` /
`DESIGN.json`, hard constraints from `direction.md`, content
sourcing rules from `reference/proposed-file-shell.md` § Content
sourcing hierarchy).
- Invoke craft through the skill-invocation tool.
- Validate the result against the contract (`:root` block, data
attributes, divergence audit, impeccable hard rules, content
sourcing). If validation fails, refuse to write — never paper over
craft output the agent thinks is "close enough."
The proposed file is whatever craft writes plus the validation
report; it is not stardust's authored artifact.
## Procedure
### Phase 1 — Plan the prototype (page-shape brief)
For each page in scope:
1. Read `stardust/current/pages/<slug>.json` for the page's structure
and content.
2. Read `stardust/current/_brand-extraction.json` for system
components and cross-promo data (the page's site-wide repeated
surfaces).
3. Read `stardust/direction.md` Active section for the resolved
direction, divergence inputs, and command sequence.
4. Read project-root `DESIGN.md` + `DESIGN.json` for the target
site system — tokens, abstract component vocabulary, named
system-component roles. The site system tells the agent *what
the design language is*; this Phase decides *how it deploys to
this specific page*.
5. **Author `stardust/prototypes/<slug>-shape.md`** — the per-page
compositional brief. Format spec:
`reference/page-shape-brief.md`. The brief carries the section
list, layout strategy, key states, interaction model, structural
data attributes, and the unsourced-content list (bridge to the
placeholder contract). Author directly — no interview, no
impeccable invocation; this is stardust's reasoning about how
the system deploys to this page given this content.
6. Show the brief to the user and wait for confirmation before
moving to Phase 2. The user can edit the brief in place
(rearrange sections, kill open questions, change composition
decisions); re-rendering Phase 2 will rebuild the proposed file
from the edited brief.
**Hands-off compliance.** When `state.json.handsOff` is true,
the shape brief is still authored and validated but the
user-confirmation wait is skipped — the brief is its own record.
Approval (Phase 5) under hands-off follows the mode's contract
defined in `skills/stardust/SKILL.md` § Hands-off mode.
`$impeccable shape` is **not** invoked in v0.2 (see
`reference/page-shape-brief.md` § Authoring procedure for the
rationale; revisit if per-page hand-authoring proves insufficient
across sites).
The brief decouples site-level concerns (in DESIGN.md) from
page-level deployment (per-page brief). A direction change
invalidates the system; existing briefs are content-aware-stale
only when the system change makes their composition impossible.
This recalibration of stale-flagging is documented in
`skills/stardust/reference/state-machine.md` § Stale flagging.
#### Brief-time disciplines (validator-enforced)
Five disciplines fire when the brief is authored. The brief
validator rejects briefs missing any of them; failure surfaces the
specific rule violated and stops Phase 1 before Phase 2 renders
anything. The disciplines exist to prevent the AI-slop failure mode
where a brief with only `(DESIGN tokens) + (captured content)` as
input produces template-shaped output regardless of brand.
**Discipline 1 — Captured-source lineage per section.** Every
section in `## Sections` declares its captured-source origin. Forms:
- *"subscription-card-on-bay (consolidates captured banner 2 +
dual-card right of `pages/home.json#landmarks[hero]`)"* — derived
from one or more captured surfaces
- *"site-wide system-component (carried from `_brand-extraction.json
#systemComponents[kind=footer]`)"* — chrome inherited from the
brand-surface
- *"direction-authorized new"* — composed against direction.md, not
derived from a captured source (require a one-line note naming
which direction movement justifies the new section)
Sections without lineage are rejected. The lineage list lives in
`_provenance.capturedSourceLineage` in the brief and propagates to
the rendered file.
**Discipline 2 — Anti-template pass.** For each captured component
pattern the page deploys (cards / banners / search rows / CTA bands
/ hero composition), the brief considers 2–3 layout alternatives
and picks the most differentiated. Curated default-patterns-to-escape
flags reflex picks:
- hero-then-bands silhouette (the universal AI silhouette)
- 5-up image-card grid as category nav
- nav-icon glyphs (search / cart / account) in a typographic
register
- centered-stack hero with two-button CTA pair
- captured-shape mirror-translated into new tokens
The brief justifies any reach for a default-pattern with a
captured-source citation that makes the pattern brand-appropriate
(e.g., *"5-up grid preserved because the captured site's grid IS
the brand's signature catalogue shape; the alternative consideration
was a vertical ledger which the brand register rejects"*).
The alternatives SHOULD be reference-grounded when reference
research is available (per
`skills/stardust/reference/reference-research.md`): an alternative
cites a real reference screen in the entry's `reference?` field
using that file's evidence shape. Taste-only alternatives remain
valid when research is unavailable.
The audit lives in `_provenance.antiTemplatePass[]` with one entry
per captured pattern: `{ pattern, defaultReflex, alternatives[],
picked, rationale, reference? }`.
**Discipline 3 — Surprise budget.** The brief declares a `surprise`
field with one of: `low | medium | high`. Moves come from the bank
of non-template moves — see
`skills/stardust/reference/divergence-toolkit.md` § Non-template
move bank, with worked examples in
`reference/anti-template-bank.md` — or an evidence-shaped extension
per the bank's § Extension rule. Tier semantics:
- `low` — brand-faithful + improvements only. Variant A's role
under reimagined; all of A1/A2/A3 under verbatim.
- `medium` (default for B variants under reimagined) — one captured
cliché replaced by one move from the bank.
- `high` (default for C variants under reimagined) — two clichés
replaced + one document-shape substitution.
Under `ia-fidelity: verbatim` (per
`skills/stardust/reference/intent-dimensions.md` § 9), the per-page
surprise budget is **capped at `low` site-wide**. The validator
refuses any verbatim-direction brief with `surprise: medium` or
`high`.
**`low` ≠ generic.** The budget bounds *added* divergence, not craft
or fidelity. `low` means **brand-faithful + improvements + full
signature preservation**, NOT "the most obvious faithful
interpretation." The recurring failure mode (a fintech migration)
is the agent reading `low` / `verbatim` as license to strip the page
to a plain type-hero on a flat ground — the result is faithful but
forgettable and under-sells the redesign. Hold the craft bar at `low`:
keep the brand's distinctive elements, apply the improvements list,
and reproduce the signature.
**Signature preservation is mandatory and budget-exempt.** When the
captured page has a signature hero medium (background video / canvas /
WebGL / Lottie), signature motion (scroll / parallax / kinetic), or a
signature visual motif (per `intent-dimensions.md` § 8b), the brief
**must** reproduce it — with a static fallback, `prefers-reduced-
motion` alternative, and (for overlaid text) a legibility scrim. This
does **not** consume the `low` allowance: carrying the brand's own
signature forward is fidelity, not divergence (§ 8b § Surprise-budget
exemption). Record the kept signatures in
`_provenance.signatureElements[]` as `{ kind, capturedSource,
mechanism, fallback }`. **Render-refusal:** a brief that flattens a
captured video/canvas/animation hero to a still, gradient, or
type-only hero — or drops a site-wide motif — is rejected at the
shape-brief audit; reproduce the signature instead.
**Type-scale yield clause.** When a tier-`medium`-or-higher variant's
captured-trait amplification structurally conflicts with a
brand-level type-scale rule from `DESIGN.md` (e.g. a
"Names-At-Headline-Scale" rule, or any other named type-scale
floor / ceiling), the brand-level rule may yield per-page. The
yield must be cited in `_provenance.surpriseTier_typeScaleYields[]`
with: `{ rule, variantDominantDimension, capturedTraitAmplified,
yieldedTo, rationale }`. The brand-level yield clause itself
(the named exception in `DESIGN.md`) is project-side, not
spec-side; the spec only requires the per-page citation when the
yield fires. See § Friction carve-out #4 below.
**Discipline 4 — Substrate transitions are deliberate, named, and
rare.** Default: single substrate across the page. Each substrate
exception requires a named purpose in the brief (*"highlights the
featured-coffee promotional moment"*). **More than two substrate
transitions per page fails the brief.** The transitions live in
`_provenance.substrateTransitions` as `{ default, exceptions[] }`.
**Exception — substrate-keyed document-shapes (friction carve-out
#2).** When the variant's `surprise: high` move is a
substrate-keyed document-shape (zine, catalog-card,
poster-sequence), the per-section substrate IS the document-shape's
structural rhythm. The ≤ 2-transition cap does not apply; each
section's substrate must instead carry a **per-section
captured-source citation** (typically a per-SKU label color, a
per-page brand color, or a per-content-type ground convention from
the captured site). The exception is recorded in
`_provenance.substrateTransitions.note` with the document-shape
named and the citation source. The validator accepts > 2 transitions
when:
1. `surprise: high` is declared, AND
2. the picked move from the bank is `document-shape` with a
substrate-keyed sub-kind (zine / catalog-card / poster-sequence),
AND
3. every transition in `exceptions[]` carries a per-section
captured-source citation.
If any of the three conditions fails, the cap re-engages.
**Discipline 5 — Heading hierarchy + voice classification tracked
per section.** The brief requires:
- H1 declared once per page; subsequent sections H2; H3 children.
- Every literal value in copy classified as one of:
`captured-verbatim`, `direction-authorized rewrite`, or
`placeholder`. No section ships with copy without a classification.
The classification list lives in `_provenance.voiceClassification[]`
as `{ section, classification, copy?, source? }` and propagates to
the rendered file.
**Placeholder-ribbon labels (friction carve-out #3).** System-
component honesty-signal labels (placeholder ribbons, "TBD" badges,
"from the brand team at migrate" markers) are **direction-authorized
chrome**, not placeholder content. They label placeholder prose /
data; the prose / data is what gets enumerated in
`_provenance.unsourcedContent[]`. The ribbon text itself does not.
Classify the ribbon labels as
`direction-authorized chrome (per friction #3)` so the placeholder
enumerator stays clean (no double-counting across every component
instance).
### Phase 2 — Render the proposed page
Render `stardust/prototypes/<slug>-proposed.html` per
`reference/proposed-file-shell.md` § Required structure. Hard
requirements there:
- `:root` token block as the first content of the first `<style>`
(per `skills/stardust/reference/token-contract.md`).
- Structural data attributes on every section (per
`skills/stardust/reference/data-attributes.md`).
- Provenance block as the first child of `<head>`.
- Self-contained: no external CSS, no external JS.
- The site's favicon inlined in the head as a data: URI when
`stardust/current/assets/favicon.<ext>` exists (per
`reference/proposed-file-shell.md` § Hard requirements #8).
- Content preserved from the current page (hero copy, CTAs, nav,
body) unless `direction.md` authorises content changes.
- **Content sourcing hierarchy** (`reference/proposed-file-shell.md`
§ Content sourcing hierarchy): every literal value rendered must
come from `current/pages/<slug>.json`, then voice samples, then
direction-authorised changes — or be rendered with the mandatory
PLACEHOLDER visual signature. Stats, addresses, quotes, tax IDs,
hours, prices, named-person words must never be invented. The
proposed file's `_provenance.unsourcedContent[]` lists every
placeholder so migrate can refuse to ship unverified content.
Delegate the heavy creative lift to `$impeccable craft`:
- Pass the page content and the resolved direction as the feature
description.
- Reference DESIGN.md / DESIGN.json as the design system.
- Pass `direction.md` § Anti-references and § Divergence inputs as
hard constraints (so craft does not silently veer off the resolved
direction).
- Skip craft's "north star mock" generation step (direction.md is the
brief). Skip craft's "shape" call (already done if Phase 1 needed
it).
**Modern-web-guidance consult.** When the render implements
scroll-driven animation, view transitions, anchor positioning,
container queries, or perf-sensitive hero media, and the
`modern-web-guidance` plugin is installed, search it
(`npx -y modern-web-guidance@latest search "<query>"`) and follow
the retrieved guide; cite the guide id in
`_provenance.guidesConsulted[]`. Skip silently when the plugin is
absent.
After craft returns, validate the output:
- `:root` block present and complete (token-contract.md).
- Data attributes on every section (data-attributes.md).
- Anti-toolbox audit clean (each hit justified per divergence-toolkit.md
§ 1; record audit results in `DESIGN.json.extensions.divergence.anti_toolbox_hits`
with the audit's amendments noted).
- Impeccable hard rules respected (OKLCH, type ratio ≥ 1.25, no
reflex slop).
- **Content sourcing scan** — every literal value in the rendered
output traces to one of the allowed sources
(`reference/proposed-file-shell.md` § Content sourcing hierarchy).
Any value that doesn't is either wrapped in a `[data-placeholder]`
element with the mandatory visual signature, or the validation
fails. Build the `_provenance.unsourcedContent[]` list during
this scan.
If validation fails, do not write the file. Surface the failure to
the user with the specific rule violated and a suggested fix.
#### Craft-time disciplines (pre-write validators)
Four disciplines fire on the rendered file *before* it lands on
disk. These run after craft returns its output and before the file
is written; failure refuses the write with a substitute proposal
(Discipline 6) or a rule citation (7, 8), and Discipline 9 registers
detector ignores rather than refusing.
**Discipline 6 — Reflex-reject font pre-flight.** Grep the
declared `font-family` declarations against the reject list in
`skills/stardust/reference/divergence-toolkit.md` § Reflex-reject
fonts. If `≥ 3` reject-list families hit, refuse to write and
propose dimensionally-equivalent off-list substitutes from the
substitute table.
The check fires only on rendered files whose `font-family`
declarations the agent had freedom to pick. **Mode A renders with
captured display + body families pinned (per
`direct/SKILL.md` § Mode A — Brand-faithful mode) bypass the
check** — the inherited families are not a reflex choice. Record
the bypass reason in `_provenance.reflexRejectAudit.bypassed` with
the captured families named.
**Discipline 7 — Variable-font axis engagement.** When the resolved
direction's `expressive` or `distinctiveness` axes have moved past
their default (per
`skills/stardust/reference/intent-dimensions.md` §§ 2 + 5), engage
≥ 1 variable-font axis non-trivially per page using deck recipes
from the divergence toolkit. The toolkit's font decks expose named
axis recipes:
- `serif-luxury` deck → Fraunces axis recipe: `opsz 144, SOFT 100, WONK 1`
- `bauhaus-functional` deck → Bricolage axis recipe: `opsz 96, wght 600`
- `tactile-humanist` deck → Recursive axis recipe: `MONO 1, CRSV 0, CASL 0.5`
Static-weight static-style across all type on a page that claims
expressive or distinctive movement fails the check.
**Static-only-family precedence (friction carve-out #1).** Family
substitution rules when the captured/pinned display font does not
ship a variable axis:
1. If the captured/pinned display font is variable, engage its
axes per deck recipes (standard path).
2. If the captured display font is **static-only by family**
(Bellfort, GT Sectra static, hand-lettered custom cuts whose
`woff2` files don't expose a parseable `fvar` table without
runtime inspection), **exempt the display family** from the
check and engage the **body family's axes** instead (typically
`wght` and `ital` on a workhorse like Public Sans or Hanken
Grotesk).
3. **Document** the family's static-only status in
`DESIGN.json.extensions.divergence.font_deck.notes` so downstream
pages don't re-run the check.
A pre-flight that blindly grep'd for `font-variation-settings`
would fire on every brand-faithful render of a static-only-display
brand. The exemption keeps the spirit of the discipline (engage
variable behavior where it exists) while honoring the letter when
the captured family literally has no axes to engage.
Off-deck accent fonts must ship with named **expressive positions**
(`marginal-tag`, `pointer-scribble`, `headline-callout`,
`badge-fill` — see toolkit § Font deck — expressive positions).
A face introduced without a position is a reflex pick, not an
expressive position.
**Discipline 8 — Fidelity tier (`--fidelity=quick|refined|production`).**
- `quick` (default) — sketch fidelity. Brief decisions land;
micro-decisions stay provisional.
- `refined` — adds a craft micro-pass per
`reference/fidelity-refined-pass.md`: formal type scale as CSS
custom properties, `font-variant-numeric: tabular-nums` on inline
digits, `text-wrap: balance` on headings + `text-wrap: pretty`
on body + `hanging-punctuation: first` on `html`, sliding
left-rule on nav hover, hairline hover on list items,
kicker + title + baseline-aligned more-link section-head triplet,
italic display couplet replacing structurally-vague `<b>`,
bottom-of-sidebar reworked as typographic plate.
- `production` — `refined` + WCAG AA audit on every render + harden
pass (loading states, error states, content-overflow edges).
The tier is declared in the run invocation; persisted in
`_provenance.fidelity`. Default is `quick`.
**Discipline 9 — Copy-cadence detector bypass under verbatim
fidelity.** This extends the Mode-A reasoning of Discipline 6 from
fonts to prose. impeccable's design detector ships prose-voice rules
(`em-dash-overuse`, `marketing-buzzword`, and similar copy-cadence
checks) that assume the copy is the agent's to rewrite. Under
`ia-fidelity: verbatim` — or any faithful/Mode-A render where the body
copy is `captured-verbatim` — that assumption is false by
construction: the prose is the source brand's, reproduced exactly per
the content-sourcing hierarchy, and rewriting it to satisfy a cadence
rule *is* the fabrication the fidelity setting exists to prevent. So
when the rendered file's copy classification is `captured-verbatim`
(per Discipline 5's `voiceClassification`), register those copy-cadence
rules as intentional ignores for the `<slug>-proposed.html` files
before the design hook fires — the same way Discipline 6 bypasses the
font reflex-reject check for pinned families. Scope the ignore to the
proposed files only, **never** to the project's own source (blocks,
styles, components), where the rules still apply because that copy
*is* the agent's. Record the bypass in
`_provenance.copyCadenceBypass` with the rules ignored and the
classification basis. A 2026-06-26 SaaS-site run hit this: the hook
flagged em-dashes and "enterprise-grade" on the site's own headings
("Built on Enterprise-Grade Components") under a verbatim direction,
and the only correct response was to leave the captured copy untouched
and record the bypass.
Bound the bypass: it covers prose-cadence rules only. Structural and
craft detector rules (`design-system-radius`, contrast failures,
reflex layout slop) are *not* exempted by verbatim fidelity — those
govern the agent's own CSS and structure, which faithful mode does not
freeze. Listing a rule under this bypass requires it be a copy-voice
rule whose subject is the captured prose.
### Phase 2.4 — Motion application (when `--cinematic`)
Fires only when `--cinematic` (with or without an explicit
register) was passed, OR when
`DESIGN.json.extensions.motion.register` was authored by `direct`
and the user did not opt out. Produces
`stardust/prototypes/<slug>-cinematic.html` **alongside** the static
`<slug>-proposed.html` — the static prototype is never replaced.
Procedure:
1. **Resolve the register.** For single-variant runs, read
`DESIGN.json.extensions.motion.register`. **For multi-variant
runs** (when `DESIGN-<id>.json` files exist at the project
root), read `DESIGN-<id>.json.extensions.motion.register` for
the variant currently being rendered — each variant may carry
its own register, or omit it entirely (variant renders
static). If `--cinematic=<register>` was passed at the CLI,
the CLI value wins **only for the variants in scope** (every
variant when no `<slug>` filter is set, otherwise th...
© adobe · Apache-2.0 · adobe/skills
Similar skills
Everything for Design →prototype by other authors comes first.