luckiest-co 1.0.13 → 1.0.15

package/skills/luckiest-website-cloner-dom/SKILL.md

@@ -0,0 +1,170 @@
+---
+name: luckiest-website-cloner-dom
+description: >-
+  Extract and rebuild the DOM/CSS layer of a web page — layout, typography,
+  colors, spacing, real content, assets, and normal interactions — into clean
+  components, section by section, from exact getComputedStyle() values rather
+  than guesses. This is the DOM/CSS track: it deliberately does NOT handle
+  WebGL/WebGPU/canvas shader surfaces (those go to luckiest-website-cloner-shaders). Usually
+  driven by the luckiest-website-cloner coordinator, but can be used directly when the user
+  wants to rebuild a page's markup/styling and there are no GPU-rendered
+  effects. Trigger on "rebuild this section", "extract the CSS/layout", "clone
+  the markup and styling of this page", or the DOM half of a full site clone.
+argument-hint: "<url> | <output-dir with surface-map.json + ROUTING.md>"
+user-invocable: false
+license: MIT. See ATTRIBUTION.md
+allowed-tools: Bash, Read, Write, Edit, Glob, Grep
+metadata:
+  version: "1.0.0"
+  listing_id: luckiest-website-cloner-dom
+  author: luckiest
+---
+
+# DOM Clone
+
+Rebuild the DOM/CSS layer of a page as clean components whose every value is
+**measured, not estimated**. The difference between a clone that reads as
+"pixel-perfect" and one that reads as "AI slop" is almost entirely whether the
+spacing, type scale, and colors are the site's real computed values or an
+approximation. So the whole method is built to remove guessing.
+
+**Scope boundary — read this first.** This track handles DOM/CSS only. Any
+`<canvas>` painting WebGL/WebGPU/2D pixels is invisible to `getComputedStyle()`
+and belongs to `luckiest-website-cloner-shaders`. When you meet a GPU surface (the surface map
+tags them, or you see a `<canvas>` you can't style your way into), do NOT rebuild
+it — leave a **placeholder mount** (below) and move on. Rebuilding a shader as
+HTML is the classic failure that makes a clone look empty.
+
+## Inputs
+
+- Driven by luckiest-website-cloner: you get an output dir containing `surface-map.json` and
+  `ROUTING.md`. Build only the sections routed to the DOM track; leave mounts for
+  GPU surfaces.
+- Standalone: you get a URL. Do a quick recon first (screenshots + the interaction
+  sweep below). If you spot GPU `<canvas>` surfaces, tell the user those need the
+  luckiest-website-cloner-shaders track and build the DOM around them.
+
+Requires a browser MCP (Chrome/Playwright/Puppeteer). Keep large extraction
+artifacts in the output dir, not the conversation.
+
+## The method: extract → spec → build → verify
+
+### 1. Foundation first (sequential, do it yourself)
+
+Nothing can be built until the shared ground exists, because every later
+component depends on it:
+
+- **Design tokens** — run `../luckiest-website-cloner/scripts/tokens-probe.js`
+  (`tokensProbe()`) at 1440/768/390 if the coordinator hasn't already left
+  `tokens-*.json` in the output dir. Its frequency-ranked palette, type scale,
+  spacing, radii, shadows, and `:root` custom props ARE the tokens — write them
+  as CSS variables / Tailwind theme, keeping the site's own `--names` when it
+  has them. Colors and fonts wrong here poison every component.
+- **Motion params** — likewise take `motion.json` (`../luckiest-website-cloner/scripts/
+  motion-probe.js`) as the source for every GSAP/ScrollTrigger/Lenis/WAAPI
+  value a spec needs. A spec that says `scrub: 1.2, start: "top top", end:
+  "+=200%"` came from the runtime; one that says "scrubs on scroll" is a guess.
+- **Fonts** — identify actual `font-family` on headings/body/labels; wire up the
+  same families (self-hosted or Google) so metrics match.
+- **Global assets** — favicons, logos, and site-wide images to the project.
+  Resolve each through the asset ladder in `references/asset-resolution.md`:
+  download the REAL file first; only fall back to reconstructing, generating
+  (Higgsfield, for decorative assets — never brand identity), or a placeholder,
+  and label which tier was used. This keeps the clone honest about what's real.
+- **Global behaviors** — smooth-scroll library (Lenis/Locomotive), scroll-snap,
+  global keyframes. See `references/interaction-fingerprints.md` to detect and
+  reproduce these; they change how sections must be built.
+
+Verify the empty shell builds before going further.
+
+### 2. Extract each section with exact values
+
+For each DOM section top-to-bottom, use the browser to capture — don't hand-
+measure:
+
+- A section screenshot (for the builder's reference and later QA).
+- **Computed styles** for every meaningful element via `getComputedStyle()` —
+  real px/color/weight values, not "looks like `text-lg`".
+- **Real content** — verbatim text, alt text, and every image/`<img>`/background
+  image in the section, including **layered/overlay** images (a hero is often a
+  background + a foreground mockup + an icon; miss the overlay and it looks bare).
+  Resolve each asset through `references/asset-resolution.md` (REAL → RECONSTRUCT
+  → GENERATE → PLACEHOLDER), tagging any that couldn't be downloaded.
+- **All states, not just the default** — for tabs/accordions click each and
+  record per-state content; for scroll- or hover-triggered changes, capture the
+  before AND after computed styles and the transition (duration/easing) plus the
+  exact trigger. See `references/interaction-fingerprints.md`.
+
+### 3. Write a spec file — the contract
+
+Write one spec per section to `<output>/specs/<section>.spec.md` BEFORE building.
+This is the contract between measurement and construction: the builder works from
+the spec, not from its memory of a browser session, so it can't drift into
+guessing. A spec has: target file, screenshot path, **interaction model**
+(static / click / scroll / hover / time), exact computed styles per element,
+per-state content, assets with local paths, verbatim text, and responsive
+behavior at 1440 / 768 / 390. If a builder would have to invent any value, the
+spec isn't done yet.
+
+For GPU surfaces in this section, the spec says only: **placeholder mount** — a
+positioned empty container with the id, size, z-index, and pointer-events from
+the surface map, for luckiest-website-cloner-shaders to fill later. Nothing more.
+
+### 4. Build — size agents to the model, not to dogma
+
+Dispatch builders that each receive their spec inline (never "go read the spec").
+On agent granularity: splitting a page into many tiny builders is a choice for
+**speed and edit-isolation**, not a fidelity requirement — a capable model holds
+a whole section's spec fine. So prefer **one builder per section** by default,
+and split further only when a section contains genuinely independent pieces
+(three distinct card variants, separate interactive widgets) that benefit from
+parallel isolation. Over-splitting just adds merge and coordination cost.
+
+If builders run in parallel and might touch shared files, isolate them (git
+worktrees or separate output subtrees) and merge with the section topology in
+hand. Each builder verifies its own typecheck/build before finishing.
+
+### 5. Verify with a real diff
+
+After assembly, run an automated pixel diff (Playwright `toHaveScreenshot()`),
+original vs clone, at all three breakpoints — **masking any GPU placeholder
+regions** so their emptiness/animation doesn't dominate the result. Tune
+`maxDiffPixelRatio` rather than demanding zero diff (anti-aliasing causes false
+positives). For each real discrepancy, decide: was the spec value wrong
+(re-extract, fix spec) or did the builder ignore a correct spec (fix component)?
+Fix at the source, not with a compensating fudge.
+
+## Output
+
+- `site/` (or the coordinator's chosen substrate) with styled sections + mounts
+- `specs/*.spec.md` — one per section, the audit trail
+- Downloaded assets under the project's public dir
+- QA diff results per breakpoint + list of placeholder mounts left for GPU track
+
+## What not to do
+
+- Don't clone from a screenshot; extract the real DOM/CSS/content.
+- Don't rebuild a `<canvas>` shader/3D effect as HTML — leave a mount.
+- Don't approximate a computed value you could have measured.
+- Don't freeze a `<video>` or animated SVG to a static image — re-embed / keep it.
+- Don't build a click-based UI when the original is scroll-driven; settle the
+  interaction model before building (it's a rewrite, not a tweak, to change later).
+
+## Guardrails
+
+Clone for migration, for recovering your own lost source, or for learning how a
+build works. Do not use it to pass off someone else's brand or design as your
+own, for phishing or impersonation, or against a site whose terms forbid
+reproduction. Logos, brand assets, and copy belong to their owners.
+
+Stop and ask the user before continuing if any of these are true:
+
+- The target looks like it exists to be impersonated: a bank or wallet login, a
+  checkout, an account or password page.
+- The page is behind a login, a paywall, or a bot wall. Never supply
+  credentials, cookies, session tokens, or a stored browser profile to get past
+  one, and never work around the block.
+- The page holds personal data about real people.
+
+Capture only what renders publicly. Do not read or copy credentials, cookies,
+local storage, or session storage from the target.

package/skills/luckiest-website-cloner-dom/references/asset-resolution.md

@@ -0,0 +1,93 @@
+# Asset resolution ladder
+
+A clone needs the page's images, videos, textures, and icons. Some you can just
+download; some are blocked (cross-origin, DRM, auth-walled); some you *shouldn't*
+copy at all (a brand's logo in a learning clone). This ladder decides, per asset,
+how to resolve it — and keeps the result honest about which tier was used.
+
+The governing rule: **a faithful clone wants the REAL asset.** Generating a
+lookalike is a fallback, never the default, and is gated by what the asset *is*.
+A generated hero-background texture raises completeness; a generated logo lowers
+fidelity AND copies brand identity. So gate by role, not by convenience.
+
+## The four tiers (label every asset with the one used)
+
+1. **REAL** — download the actual file to the project (`<img src>`, `<video>`,
+   background-image, source-set). Default. Highest fidelity. Always try first.
+2. **RECONSTRUCT** — rebuild it yourself when it's cheaply rebuildable: an inline
+   SVG you can extract, a CSS gradient, a canvas/WebGL effect (hand to
+   luckiest-website-cloner-shaders). Faithful and license-clean.
+3. **GENERATE** — synthesize a substitute via the Higgsfield MCP. Only when 1 and
+   2 both fail or are disallowed. Label the asset `GENERATED` and log it in
+   `known-gaps.md`. Never let a generated asset be reported as REAL.
+4. **PLACEHOLDER** — a solid block, blurhash, or captured poster frame, when
+   generation isn't wanted or the asset is identity/content (below).
+
+## Gate by role — the decision that matters
+
+**Decorative / demo assets → GENERATE is appropriate** when REAL/RECONSTRUCT fail:
+- hero or section **background video/image** that's blocked or heavy
+- ambient **textures**, noise maps, gradient meshes, particle sprites
+- a **poster frame** for a shader/canvas that couldn't be reconstructed
+- filler **product/UI mockups** in a demo where exact content doesn't matter
+
+**Identity / content assets → NEVER generate. REAL-or-PLACEHOLDER only:**
+- **logos**, wordmarks, brand icons
+- real **UI screenshots** / product imagery that carries meaning
+- **photos of real people**, testimonials, author avatars
+- anything where a generated substitute would misrepresent the original
+
+Generating identity assets makes the clone *less* faithful and copies brand
+identity — both wrong. If you can't get the real one, use a neutral placeholder
+and note it.
+
+## Special case: composited live-UI mocks (the download trap)
+
+The most common asset mistake on modern product sites: a hero or feature visual
+that *looks* like one image is actually a **live UI composited in HTML over a
+static background image** — a fake app window, code panel, or dashboard layered
+on a painterly/gradient wallpaper. If you naively download the background image
+(tier 1 REAL), you get an empty wallpaper with none of the UI, because the UI was
+never in that file. Worse, sites often **reuse the same wallpaper** across several
+feature blocks, so an nth-image match lands on the wrong block's background.
+
+How to handle it:
+
+- **Recognize it:** the region contains real DOM (text nodes, buttons, code) on
+  top of an `<img>`/background whose natural size ≈ the whole region and whose
+  content is just texture. If getComputedStyle sees real child elements over an
+  image, it's composited — not a flat asset.
+- **Capture, don't download:** screenshot the composited region as a whole
+  (Playwright `clip` at the region's box) → tier is CAPTURED, not REAL. This is
+  the faithful static representation of a live composition.
+- **Reused-wallpaper guard:** don't trust "the nth `<img>`" to identify the
+  block — capture by the region's own bounding box at the scroll offset where it's
+  fully visible (see the scroll-pinned note in `interaction-fingerprints.md`).
+
+Label these CAPTURED in the report so it's clear the pixels are a snapshot of a
+live composition, not a downloaded source asset.
+
+## Calling Higgsfield (tier 3)
+
+Match the tool to the asset. Follow the creative-direction rule: for anything
+non-trivial, propose 2–3 directions and get a pick before burning credits.
+
+- **Image** (texture, background, mockup) → `generate_image` (GPT Image 2 for
+  design/text-in-image; Nano Banana for reference-driven). Feed it the surface's
+  role, palette (from design tokens), and aspect/size from the surface map.
+- **Video** (hero background loop) → `generate_video` (Seedance for generic
+  motion). Match duration/aspect/muted-loop to the original `<video>` element.
+- **Import a specific asset you found but can't hotlink** → `media_import_url`.
+- **Cutout / transparent** → `remove_background`.
+
+Write generated assets into the project's asset dir with a filename tagged
+`-generated` and record in `known-gaps.md`: original URL (if any), why REAL/
+RECONSTRUCT failed, the prompt used, and the tier. This keeps the clone auditable
+and the fidelity claim honest.
+
+## Reporting
+
+In the completion report, break assets down by tier: N REAL, N RECONSTRUCT, N
+GENERATED, N PLACEHOLDER. A clone that's 90% REAL with 3 clearly-labeled
+GENERATED decorative textures is honest and complete. A clone silently padded
+with generated brand assets is neither.

package/skills/luckiest-website-cloner-dom/references/interaction-fingerprints.md

@@ -0,0 +1,85 @@
+# Interaction fingerprints
+
+The most expensive mistake when rebuilding a section is getting its **control
+model** wrong — building click-switched tabs when the original auto-switches on
+scroll, or static CSS when the original runs a smooth-scroll library. Fixing it
+later is a rewrite, not a tweak, because it changes the component's whole
+structure. So identify the mechanism during extraction, from concrete signatures,
+not from how it looks.
+
+## Determine the model by observing, in this order
+
+1. **Scroll first, don't click.** Slowly scroll the section. If content changes,
+   panels swap, or a sidebar's active item advances on its own as you scroll,
+   it's **scroll-driven** (IntersectionObserver / scroll timeline / sticky). Note
+   the trigger (scroll position or intersection ratio).
+2. **Then click.** If nothing changes on scroll, test clicks — real tabs/pills
+   that swap content on click.
+3. **Then hover.** Record hover state changes (color/scale/shadow) with their
+   transition duration + easing.
+
+Record the verdict explicitly in the spec: `INTERACTION MODEL: scroll-driven
+(IntersectionObserver)` etc.
+
+## Smooth-scroll libraries
+
+Native browser scrolling feels different from a lerp-smoothed library; users spot
+it instantly, so a clone must reproduce the same scroll feel. Detect by
+signature:
+
+- **Lenis** (the dominant current library) — a `Lenis` runtime global, a `lenis`
+  class on `<html>`, and/or `data-lenis*` attributes (e.g. `data-lenis-prevent`).
+  It smooths the browser's own native scroll (so sticky/anchor/accessibility keep
+  working) rather than transform-hijacking the page — reproduce it by adding Lenis
+  with matching lerp/duration, not by faking scroll with transforms.
+- **Locomotive Scroll** — `data-scroll`, `data-scroll-container`,
+  `data-scroll-section`, `data-scroll-speed` attributes. Current versions are
+  built on top of Lenis, so a Locomotive page often shows Lenis signatures too;
+  reproduce with Locomotive (or Lenis + the same `data-scroll-speed` parallax).
+
+The surface-map script already reports these under `scroll`. Trust that as the
+first pass, then confirm the feel.
+
+## Scroll-driven CSS animations
+
+Modern sites increasingly drive animations off scroll/view progress instead of
+time, with no JS. Their fingerprint is CSS: `animation-timeline` set to something
+other than `auto`, plus `scroll-timeline-name` / `view-timeline-name` (and their
+`-axis` / `-inset`). When present, rebuild with the same scroll/view timeline —
+don't approximate it with a JS scroll listener, which will feel and perform
+differently.
+
+## Behaviors to catch (illustrative, not exhaustive)
+
+- Navbar that shrinks / gains a shadow / changes background past a scroll
+  threshold — capture styles at position 0 and past the trigger; diff them.
+- Elements that animate into view on entering the viewport (fade-up, stagger).
+- Sticky sidebars whose active item auto-changes as content scrolls (Intersection
+  Observer, NOT click handlers) — the classic scroll-vs-click trap.
+- Parallax layers moving at different rates than scroll.
+- Auto-playing carousels / cycling content (time-driven).
+- Section-to-section theme flips (dark↔light) tied to scroll.
+
+For any stateful element, extract **every** state's content and styles plus the
+transition between them — a clone that only captures the load-time state looks
+broken the moment the user interacts with it.
+
+## Capturing assets inside scroll-pinned / sticky sequences
+
+A common modern pattern: a tall feature section where a sticky column stays fixed
+while paired content scrolls, swapping the visible mock per feature (`position:
+sticky` + IntersectionObserver). Two traps when capturing the paired visual:
+
+- **Don't trust "the nth image."** These sequences frequently reuse one
+  background/wallpaper image across every block, so an nth-`<img>` selector lands
+  on the wrong block's asset. Identify the block by its own container's bounding
+  box, not by image index.
+- **Capture at the paired scroll offset.** The correct mock for feature N is only
+  fully composited/visible when the section is scrolled to N's active range.
+  Scroll to that offset first, then clip the region — capturing at scroll 0 gives
+  you the first (or an empty) frame. Record the offset in the spec so the capture
+  is reproducible.
+
+If you only need a static clone, one clean full-row capture at the right offset is
+enough; if you're rebuilding the pin behavior, also record the trigger ranges per
+block (which one is active at which scroll position).

package/skills/luckiest-website-cloner-remix/ATTRIBUTION.md

@@ -0,0 +1,4 @@
+# Attribution
+
+See `../luckiest-website-cloner/ATTRIBUTION.md`. Luckiest edition of the
+open-source site-clone skill collection, MIT licensed.

package/skills/luckiest-website-cloner-remix/CHANGELOG.md

@@ -0,0 +1,8 @@
+# Changelog
+
+## 1.0.0
+
+First Luckiest edition of `luckiest-website-cloner-remix`. Renamed from the upstream site-clone
+collection, guardrails added to every entry point, recipes added for running the
+probes from an in-app browser pane, frontmatter normalized to the Luckiest
+package format. See ATTRIBUTION.md.

package/skills/luckiest-website-cloner-remix/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 Chase Hannegan
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/skills/luckiest-website-cloner-remix/SKILL.md

@@ -0,0 +1,202 @@
+---
+name: luckiest-website-cloner-remix
+description: >-
+  Turn a cloned (or any measured) website into YOUR site: re-skin it with your
+  brand, copy, and assets; generate three deliberately different design
+  directions as token/motion/shader overrides and render them side by side;
+  then put a live tweak panel on the direction you pick. This is the step after
+  /luckiest-website-cloner — it consumes the clone's TEARDOWN.md, tokens-*.json, motion.json,
+  and site/ and never re-probes. Use when the user says "/remix", "remix this
+  clone", "make this mine", "re-skin this", "give me three versions of this
+  site", "variations of this design", "add a tweak panel", "let me tune the
+  colors/spacing/motion", or has just approved a clone and wants to move from
+  copying to owning. NOT for cloning (use /luckiest-website-cloner) and NOT for building a
+  site from scratch.
+argument-hint: "<clone-dir or site-dir> [--phase reskin|directions|panel]"
+user-invocable: true
+license: MIT. See ATTRIBUTION.md
+allowed-tools: Bash, Read, Write, Edit, Glob, Grep, AskUserQuestion
+metadata:
+  version: "1.0.0"
+  listing_id: luckiest-website-cloner-remix
+  author: luckiest
+---
+
+# 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 `/luckiest-website-cloner`, which runs autonomously):
+
+1. **Re-skin** — swap the three things that make it *theirs*: copy, brand, hero
+   assets. Output: a de-branded template. Non-negotiable and first.
+2. **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.
+3. **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 luckiest-website-cloner 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 `../luckiest-website-cloner/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:
+
+```bash
+node scripts/tokenize-css.cjs <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 `../luckiest-website-cloner-dom/references/asset-resolution.md`
+  with 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) — see `references/reskin.md` for 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.md` has
+  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):
+
+1. **Amplitude** — *subtle* / *medium* / *big*?
+   | | moves | layer |
+   |---|---|---|
+   | subtle | palette, accent, motion timing, shader colors | `overrides.json` only |
+   | medium | + surface (radius/border/shadow), density (spacing ×), type scale + weights, grain | + `patch.css` |
+   | big | + hero treatment (photo → type-only / GPU-led / engraving), layout (grid ↔ editorial ↔ bento), section order, nav style, own hero asset per direction | + `patch.js` + generated assets |
+   If unsure, recommend **medium** — subtle reads as "same site, different coat"
+   side by side; big costs generations.
+2. **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 from `references/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.cjs` 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.cjs <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.cjs <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.