/react

name: react
description: >
  Clone a captured website into verified shadcn/ui React components — a capture
  session becomes one component per route with its captured states as props,
  themed from the site's own tokens, every state gated against its own reference
  screenshot. Use when the deliverable is a real component tree rather than a
  static page: an app, a dashboard, a console, anything with behaviour (hover,
  focus, keyboard nav, a command palette, tabs, dialogs), or whenever the user
  says React, shadcn, components, or wants the clone to be maintainable rather
  than a flat file. Also use when several captures differ only by URL fragment —
  those are one component with states, not separate routes. Prefer the html
  skill for a landing or marketing page where a static file is the deliverable.

clone:react — capture session → verified shadcn routes

**In:** a session folder — `pages.json` + one folder per page holding `ref.png`, `source.html`, `computed.json`, `meta.json`. **Out:** a vite + shadcn project at `apps/<site>/ui/`, one React component per route in `ui/src/routes/`, themed from `ui/theme.json`, where every captured state's `check` exits 0 against its own `ref.png`.

**Read [`references/pipeline.md`](../../references/pipeline.md) first** — the CLI, the phases, the loop discipline and the four hard nevers are there and are not repeated here. This file is only what differs for React.

clone prep <session> --target react
clone extract | resolve | cluster
clone init | map | check | build

Why components, and where the project lives

**A screenshot is the resting frame of components that have behaviour.** A command palette cloned as HTML is a `div` with a fake list; composed from `Command` it filters, takes `⌘K`, traps focus and returns a value. Hover, focus rings, disabled states and keyboard nav are all in the component and none of them are in `ref.png`. Cloning frames throws that away every time.

**The project lives inside the capture folder it clones** — `apps/<site>/ui/`, one per site, not one for the repo. It costs a `node_modules` per clone and buys three things: a tree you can hand to someone whole, a `components/ui/` that is unambiguously *this* site's to edit, and no path in the loop that leaves the app folder — the fonts and baked glyphs the route asks for are project assets under `ui/public/`, not a sibling directory two levels up.

What prep does differently: states, not duplicate routes

**A URL that differs only in its fragment is folded into a state.**

new: 1 component, 3 states — base, settings-general, settings-customize-connectors

Under a static target those three captures are three routes, which means hand-cloning the same shell into three files and fixing every bug three times. Here they are one component and a `state` prop, each still gated against its own `ref.png`. This is most of what the target buys.

extract · resolve · cluster

Same phases, two outputs used differently:

• **`shared/glyphs.json` names become lucide-react imports.** `resolve` already

matched every glyph to a `lucide:<name>`, so `<SearchIcon />` is a lookup, not a decision. Icon *colour* comes from `currentColor` and the component.

• **A glyph you set to `keep` is a file `resolve` bakes**, and it lands in the

project at `ui/public/icons/`, so the route asks for `<img src="/icons/<file>.svg">` — one path, resolved the same by `vite dev` and `vite build`. `resolve` legitimately runs before the project exists; `init` moves them then.

• **`shared/tokens.css` feeds `init`, not your markup.** You never paste a hex

into a route.

init — the project, and the capture's values as tokens

First run tells you the one-time project command, to run **in the app folder**:

cd apps/<site> && pnpm dlx shadcn@latest init --name ui --template vite \
  --base radix --preset nova --no-monorepo --yes

Nothing else to install — no bundler plugin, because there is no bundle in the loop. Drop the `.git` that `shadcn init` leaves behind, or the outer repo sees a gitlink instead of your routes.

Then `init` writes `ui/theme.json` — the capture's values in shadcn's semantic slots. It derives what a histogram can derive (`background`, `foreground` and the base font from the capture's root; `sidebar` from the tall narrow box every route shares; `border` from the most common non-zero border; `primary` as the highest-chroma colour; `radius`, the text scale and its line-heights by frequency) and **leaves the rest null**, because which of twelve greys is `muted` and which is `accent` is a naming decision, and naming is the one thing a histogram cannot do. Name them from `candidates` (frequency-ranked, what the site actually uses — do not invent), then re-run `init` to generate `theme.css`.

Get this phase right and the loop gets short: **a wrong token fails two hundred boxes across four routes and one edit fixes all of them.** That is the trade this target makes for the Tailwind translation layer, and it only pays if the tokens are real.

`init` also regenerates `vite.config.ts`, `index.html`, `src/main.tsx`, `src/clone-env.d.ts`, `src/theme.css` and `src/fonts.css`, and copies the capture's woff2 into `ui/public/fonts/`. Those are not yours to edit; two things in them matter:

• **route and state come from the query string**, `?route=<entry>&state=<state>`,

and `main.tsx` reaches every route through `import.meta.glob`. That is what lets one dev server answer every captured state.

• **`@font-face` with `url("/fonts/…")`**, served from `public/`. `init` reads

each cut's weight, style and stretch out of its filename — declaring four static cuts at `1 1000` makes them all equal matches and Blink renders the whole page in whichever came last.

`init` writes one route stub per entry, listing the states it must serve. Stubs are never overwritten.

map — which component each node already IS

Writes `shared/shadcn.md`: every node the capture desc