Remix Site
A clone is a measured design system plus a proven structure. The teardown
already enumerated every knob — palette, type scale, spacing rhythm, motion
params, shader props, section order. Remixing means changing what flows
through those knobs, in three phases that each stop for the user's call
(unlike /clone-site, which runs autonomously):
- Re-skin — swap the three things that make it theirs: copy, brand, hero assets. Output: a de-branded template. Non-negotiable and first.
- Directions — three deliberately different combinations of the big forks (palette mood × type pairing × hero treatment × motion personality), rendered side by side. The user picks one.
- Tweak panel — the chosen direction's 10–15 real knobs made live in the page, with permalink state. Not 80 sliders; the ones they'll keep turning.
--phase runs a single phase (e.g. a second re-skin for another client, or a
panel on a site that never came from the cloner).
Inputs (the clone-site contract)
Resolve $ARGUMENTS to a directory and look for:
| File | Used for |
|---|---|
TEARDOWN.md |
stack, effects table, assets table, known gaps |
tokens-*.json |
the measured design system — the knob list |
motion.json |
exact animation params — the motion knobs |
surface-map.json |
which regions are GPU (shader knobs live here) |
site/ |
the rebuilt project (Vite/Next) |
assets/ or site/public/assets/ |
original assets, tiered |
If only site/ exists (not a clone), run tokens-probe.js and
motion-probe.js from ../clone-site/scripts/ against the dev server once to
produce the JSON — then proceed. Never re-probe when the JSON is present.
Phase 0 — Tokenize (mechanical, do it before anything)
The clone's CSS is full of literal values (#1f3bff, 32.04px). Nothing can be
varied until those literals become variables. Run:
node scripts/tokenize-css.js <site>/src/<site>.css <tokens-1440.json> <site>/src
It rewrites the stylesheet so every measured token value goes through
var(--rx-<role>, <original>) and writes remix-tokens.css (the defaults). If
the site already exposes its own --vars (Nuxt/Vue sites often do), the script
aliases those instead of inventing new names — keep the site's vocabulary.
Route motion through a config too: the clone's behavior JS should read from
window.__remix.motion (seeded from motion.json → remix-motion.js), and
shader mounts from window.__remix.shaders. If the builder hard-coded them,
hoist now. This is the one code change remix makes to the clone — everything
after is data.
Verify the site still renders identically (qa/diff.mjs against itself before
/after: must be 0%). Show the user the knob list (remix/knobs.json) and
stop: "These are the N things we can turn. Re-skin next?"
Phase 1 — Re-skin
Ask for, in one batch: brand (name, logo file or "generate a placeholder mark", primary + accent colors or "derive from logo"), copy (a doc/URL to pull from, bullet points to expand, or "placeholder in their structure"), and hero/section assets (files, or "generate").
Then:
- Copy — replace every text node section by section, keeping the original's shape (eyebrow / headline / sub / CTA / card counts). Headline lengths matter for layout: match ±20% characters or the hero reflows. Note any overflow in the report.
- Brand — logo into the header/footer slots; primary/accent into
remix-tokens.css; favicon/OG. - Assets — resolve through
../dom-clone/references/asset-resolution.mdwith the roles flipped: the original's REAL assets are now the thing to remove. Decorative (hero background, textures, ambient imagery) → GENERATE via Higgsfield using the original's composition as the brief (aspect, subject placement, mood) — seereferences/reskin.mdfor the brief template. Identity (their logo, their people, their product shots) → must be replaced, never kept. Fonts: if the original's are commercially licensed, swap to an open pairing with matching metrics (references/reskin.mdhas the lookup); if open, keep. - Remove analytics, their API endpoints, their links.
Render, screenshot the hero + two sections, stop: "This is the template with your brand. Directions next?"
Phase 2 — Three directions
Ask first, one batch, before touching anything (this is the question that decides whether the directions are coats of paint or actually different sites):
- Amplitude — subtle / medium / big?
moves layer subtle palette, accent, motion timing, shader colors overrides.jsononlymedium + surface (radius/border/shadow), density (spacing ×), type scale + weights, grain + patch.cssbig + hero treatment (photo → type-only / GPU-led / engraving), layout (grid ↔ editorial ↔ bento), section order, nav style, own hero asset per direction + patch.js+ generated assetsIf unsure, recommend medium — subtle reads as "same site, different coat" side by side; big costs generations. - Anchors — "any aesthetics in mind?" none / describe it / reference
sites or images / pull from my taste library (
/taste-vault). With none: nearest-legit / opposite / wildcard fromreferences/directions.md. With anchors: one direction per anchor, built toward it, and say which fork each anchor maps to so the user sees the translation.
Not five. Five converge; three deliberately different forks give a real choice.
Each direction is data + an optional patch layer, scoped to
:root[data-rx="<slug>"] so directions never collide:
remix/directions/<slug>.json
{ "name": "...", "thesis": "one line",
"tokens": { "--rx-accent": "#…", "--rx-font-display": "…", "--rx-space-unit": "…" },
"motion": { "reveal": { "y": 22, "duration": 0.7, "ease": [.16,1,.3,1] }, "stagger": 0.08 },
"shaders": { "hero": { "colorFront": "#…", "intensity": 0.5 } },
"assets": { "hero-bg": "generated/<slug>-hero.jpg" } }
remix/directions/<slug>.patch.css (medium+) surface / density / type scale under :root[data-rx="<slug>"]
remix/directions/<slug>.patch.js (big) structural: hero variant, section order, layout classes
apply-overrides.js picks up <slug>.patch.css / .patch.js next to the
JSON automatically. Patches must be additive and scoped — never edit the
base HTML/CSS for a direction, or the other two break.
Derive the three from the original's axes, not from taste alone — see
references/directions.md for the fork table (palette mood, type pairing, hero
treatment, density, motion personality) and the rule that each direction must
differ on at least three forks. If the user has a taste library
(/taste-vault or reference images), pull the directions from there. Generate
per-direction hero assets only for the decorative layer.
Apply each with node scripts/apply-overrides.js <site> remix/directions/<slug>.json
(writes remix-tokens.<slug>.css + remix-motion.<slug>.js; the site loads
the active set via ?rx=<slug>). Then node scripts/gallery.js <site> writes
<site>/directions.html: all directions live side by side in iframes (real
shaders + motion), synced scroll, click-a-name fullscreen, and a pick button
that stores the choice in localStorage.rx-pick. Open it in the user's browser
(this is the deliverable — not a static contact sheet), and also render
remix/directions.jpg for the report. Stop with the URL and one line per
direction: thesis + what changed. The user picks (read rx-pick or ask).
Phase 3 — Tweak panel
On the pick only. Choose 10–15 knobs from knobs.json — the ones that
matter for this direction (accent, display font size base, section spacing
unit, radius, reveal distance/duration/ease, stagger, shader intensity/colors,
hero gradient angle, grain opacity). Write remix/panel.json
(references/tweak-panel.md has the schema: type, range, step, default, CSS
var or motion/shader path) and inject scripts/tweak-panel.js into the site.
The panel: fixed, collapsible, grouped (Color / Type / Space / Motion / GPU),
writes CSS vars live, pokes window.__remix for motion/shader knobs and
re-renders the affected mount, serializes state into #rx= so a URL is a
permalink, and has Copy JSON / Reset / Export-as-direction. Keyboard: `
toggles it. It is dev-only — stripped from the production build.
Verify: every knob visibly changes the page, permalink round-trips, reset returns to the direction's defaults. Screenshot with the panel open.
Completion report
- Template: what was replaced (copy sections, brand slots, assets by tier — GENERATED assets listed), fonts kept/swapped and why
- Directions: the contact sheet + the three theses + which was picked
- Panel: knob list, permalink example
- Still theirs: anything structural you kept verbatim that the user should know about (section order, interaction patterns) — a remix is legitimate because the expression is new; say plainly what the skeleton still owes to the original
Guardrails
Phase 1 is mandatory before anything ships: no remix leaves with the original's logo, copy, people, product imagery, or licensed fonts. If the user asks to skip re-skinning and just "change the colors", say why that's still their site and do Phase 1 first.