React Screenshot Recreator

React Component Screenshot Recreator

Turn a screenshot of an interface into React code that a designer would look at, next to the original, and struggle to tell apart.

The failure mode this skill exists to prevent is the plausible approximation: code that captures the gist — a card, a heading, a button — while getting every spacing value, weight, radius, and shadow slightly wrong. The result feels like a sketch of the design rather than the design. Slightly wrong everywhere reads as unmistakably wrong.

Two habits prevent it. First, measure before you write — read values off the image instead of reaching for defaults. Second, reason about intent — real interfaces are built on a spacing scale, a type ramp, and a small palette, so when one value is ambiguous, infer it from the system the rest of the design reveals.

Workflow

1. Audit the screenshot — a written pass over layout, type, color, effects, and state. Details you don't name, you won't build.
2. Derive the design system — spacing unit, type ramp, palette, radius scale, shadow scale.
3. Plan the component tree — decide what's reusable before writing any JSX.
4. Write the code — TypeScript, Tailwind, semantic HTML, lucide-react icons.
5. Verify against the image — walk the audit list and check each item landed.

Steps 1 and 5 are what separate a recreation from an approximation. Don't skip them, and don't collapse the audit into a single glance — writing the observations down is what makes them actionable.

Step 1 — Audit the screenshot

Look at the image carefully and write out what you see, before any code. If multiple screenshots were provided (different breakpoints, states, or scroll positions), audit each and note what changes between them — that's free information about responsive and interactive behavior.

Zoom mentally into each region. State values as numbers, not adjectives: "24px gap", not "generous spacing". A number can be translated to Tailwind; an adjective can't.

Cover:

Layout — overall structure (flex row/column, grid with N columns, absolute overlay), container max-width, outer padding, gaps between siblings, internal padding of each box, alignment (start/center/baseline/stretch), and anything that breaks the flow (a badge pinned to a corner, an avatar overlapping a card edge, a sticky header).

Typography — for every distinct text style: size, weight, line height, letter spacing (tight tracking on large headings is extremely common and its absence is very visible), color, case, and truncation. Note the hierarchy: which is the display size, which is body, which is the small muted label.

Color — background layers (page vs. surface vs. elevated surface — they're often 2–4% apart and that difference is the whole look), text colors at each level of emphasis, border colors, accent/brand color, and gradients (direction, stops, and whether the stops are colors or transparent-to-color).

Depth and effects — shadows (spread, blur, y-offset, opacity, and whether there are two layered shadows, which is the norm in good design systems), borders (width, color, whether it's a hairline at low opacity), backdrop blur, glow, inner highlights, noise, rings.

Components — name each archetype you recognize (navbar, hero, feature card, pricing tier, avatar group, badge, progress bar, tab set, accordion, modal, chart). Naming them tells you which conventions to apply and where the reusable boundaries are.

Media — images and icons: dimensions, aspect ratio, crop behavior, corner radius, any overlay or shadow. Identify icons by shape so you can match them to lucide-react.

Implied behavior — hover treatments, active/selected states visible in the shot (one tab is underlined, one nav item is brighter, one pricing card is "highlighted"), focus rings, disabled styling, transitions the design clearly wants (a lift on a card, a color shift on a button).

references/visual-audit.md has the full checklist with the specific things that are easiest to miss. Read it on the first recreation of a session, or any time the screenshot is dense.

Step 2 — Derive the design system

Before writing JSX, collapse your measurements into a small system. This is what makes the output both accurate and maintainable, and it's how you resolve ambiguity honestly.

• Spacing unit — nearly every real design snaps to a 4px or 8px grid. Once you spot it, round your measurements to it. A gap you read as "23px" is 24px.
• Type ramp — the sizes you measured almost certainly form a recognizable scale (12/14/16/18/20/24/30/36/48/60). Snap to it.
• Palette — map each observed color to the nearest Tailwind token when it's close (within a couple percent of lightness); use an arbitrary value like bg-[#0B0F19] when it isn't. Brand colors are usually arbitrary; grays are usually tokens.
• Radius scale — typically 2–3 values across a design (e.g. 8px for inputs, 12px for cards, full for pills).
• Shadow scale — usually 2–3 elevations.

If a value is genuinely unreadable from the image, choose the one the system predicts. That's inference, not guessing, and it's why this step comes before the code.

Step 3 — Plan the component tree

Split where the design repeats or where a section is conceptually independent. Three pricing cards means one PricingCard with props, not three JSX blocks. A page-level screenshot means Navbar, Hero, FeatureGrid, Footer as siblings.

Don't over-split. A Divider component that renders one <div> adds indirection for nothing. The test: would you reuse it, or does naming it make the parent easier to read? If neither, inline it.

Define a props interface for anything that varies, and colocate the content as a typed data array so the markup stays clean:

const tiers: PricingTier[] = [ /* ... */ ];
// ...
{tiers.map((tier) => <PricingCard key={tier.name} {...tier} />)}