livery

livery

!checklist init ${CLAUDE_SKILL_DIR} --force

A livery is the coordinated visual identity a fleet wears — one paint-and-color scheme applied so every vessel reads as the same family, never repainted by hand per ship. livery is the visual-craft lens of the surface suite: where the other skills decide what is true (boundaries, source of truth, the four states), livery decides what it looks and feels like — and makes that a system, not a pile of ad-hoc values. Its product is a written visual system: a tokenized color-and-light scale, a modular type scale with its spacing scale, a single-light-source depth model, and a purpose-driven motion language — each committed before components consume it. It runs across gated stages and will not advance past a GATE until the checklist tool clears it — order enforced, substance yours.

The governing fact: a polished interface is values derived from a small system; an amateur one is values picked one at a time. The same #3B82F6 typed in nineteen places, a font-size chosen by nudging until it "looks right", a padding: 13px here and margin-top: 22px there, a box-shadow invented per component, a 200ms transition copied from a tutorial — each is a hand-picked value, and their sum is the visual incoherence the eye reads as "cheap" without being able to name it. The craft is the same subtraction the rest of the suite preaches: define a small system (a few tokens, a scale, one light source, a motion purpose), then derive every concrete value from it. Do that and two things happen — the surface becomes coherent (a thousand values agree because they came from ten), and it becomes evolvable (re-theme, dark-mode, or rebrand by changing the system, not finding-and-replacing the thousand).

This is where the agent era bites:

• The agent picks plausible-but-incoherent values and feels no wrongness. It will emit #2563eb here and #2f6ae0 there, a 1.31 then a 1.27 type ratio, a different gutter per component, four different shadow recipes — each defensible alone, the set visually noisy. It has no nervous system to flinch at 90ms of jank or a 4.2:1 contrast. The values must come from a decided system, not per-call taste.
• The agent reaches for the cheap trick. Dark mode by filter: invert(), depth by one fuzzy box-shadow, "animation" by a default transition: all 0.3s, a rainbow for a data series. Each is the move that looks like the craft and isn't.
• The agent treats motion as decoration. It animates because it can, not because the motion has a job — so transitions fire with no purpose, jank under load by animating layout properties, and ignore prefers-reduced-motion entirely.

Read references/the-membrane.md first — the suite's heart; for livery, lean on the axis the README names load-bearing: the benchmark is a human nervous system, so taste cannot be outsourced (16ms is a fusion threshold, 100ms is "I caused that"). Every gate here is a taste decision the agent cannot make for you; what it can do is enforce the system once you've set it. Load at the start, re-check at every gate.

Speak the user's language. The decisions are the user's — which color system, which type scale, which spacing density, how much depth, what motion is for. Read their fluency and gloss a term on first use (perceptual color / oklch, contrast ratio, type scale / modular ratio, fluid sizing / clamp(), measure / line-length, spacing scale / base unit, elevation / light model, design token, spring vs easing, prefers-reduced-motion). A token system the user can't read is a style imposed, not shared.