Give Claude Code a Website's Component Styles

Contents

• [Start with a component inventory](#start-with-a-component-inventory)
• [Capture rules Claude Code can implement](#capture-rules-claude-code-can-implement)
• [Turn observations into a handoff](#turn-observations-into-a-handoff)
• [Check the result before shipping](#check-the-result-before-shipping)
• [Use this in your AI agent](#use-this-in-your-ai-agent)

To give Claude Code a website's component styles, collect the visible rules behind the interface and turn them into a structured brief with examples and boundaries. Record typography, colors, spacing, borders, states, and responsive behavior separately so Claude Code can reproduce the system without guessing from a screenshot.

Start with a component inventory

List the components you need before asking for code. A useful first pass includes navigation, buttons, links, inputs, selects, search fields, cards, list rows, tabs, filters, pagination, alerts, banners, empty states, modals, tooltips, dropdowns, tables, headings, labels, body text, and captions.

For each component, record its purpose, variants, dimensions, spacing, text treatment, visual states, and responsive changes. Begin with “recreate these observed rules for these components,” rather than “make it look like this site.” The first request gives Claude Code a clearer target and makes missing information visible.

The examples below are useful for comparing presentation and hierarchy. They do not prove that the referenced companies use identical internal systems.

Capture rules Claude Code can implement

Typography: Name the visible family when it is available, then list roles such as body, navigation, heading, label, and code. Include approximate sizes, weights, line heights, and letter spacing. The supplied Linear example shows Inter at weight 400 for body copy, labels, navigation, and controls, with weight 500 for headings and emphasized interface text. Treat this as an observed example, not a universal recommendation.

Color: Separate page background, surface, primary text, muted text, border, accent, success, warning, and error colors. Note where each color appears and whether it changes in dark mode. A role-based description such as “muted text for secondary metadata” is more useful than a list of unassigned hex values.

Spacing: Define a small scale rather than listing every distance. Record common gaps inside controls, between card sections, around headings, and between major page sections. Mention where the rhythm changes at smaller widths.

Shape and depth: Describe border widths, radii, shadows, gradients, and dividers by component role. Say whether a card uses a visible border, surface contrast, or both. Note whether controls are more or less rounded than content containers.

States: Include default, hover, focus, pressed, disabled, selected, loading, error, and empty states. Resting screenshots rarely reveal the details that make an interface usable.

Turn observations into a handoff

Give Claude Code a brief with five parts:

1. Goal: Explain what is being built and which pages or components are in scope.
2. Reference observations: List what was seen, with links or captures for context.
3. Tokens: Provide named values for type, color, spacing, radius, border, and shadow.
4. Component rules: Describe variants, states, content limits, and responsive behavior.
5. Acceptance checks: State what must match and what can be adapted.

Ask for tokens first, then component examples, then page composition. This reduces one-off values and makes later changes easier. If a reference has a distinctive layout, describe the layout rule instead of requesting a pixel-perfect copy.

Keep observations separate from implementation choices. “The reference uses muted metadata below the title” is an observation. “Use 13px gray metadata in our implementation” is a decision. Label each item as observed, inferred, or proposed. This makes the brief easier to correct when a recommendation does not work for your product.

Check the result before shipping

Review the generated interface at the same viewport sizes as the reference. Compare the first screen, navigation density, heading wraps, control heights, card spacing, text contrast, and behavior at narrow widths. Then test interaction states rather than checking only a static screenshot.

Use this checklist:

• Are the most important actions visually obvious?
• Do headings and body copy keep the intended hierarchy?
• Are muted labels readable?
• Do focus and error states remain visible?
• Do cards and controls align to a consistent spacing scale?
• Does the layout simplify rather than merely shrink on mobile?
• Are copied details marked as observations rather than official internal data?

A website analysis pass can identify visible typography, colors, spacing, borders, component styles, and page structure from a captured site. Use those observations in the handoff, validate the result against the live experience, and adapt the rules to your own product.

Use this in your AI agent

> Inspect this website and create a Claude Code implementation brief for its visible component styles. Inventory the components, identify typography roles and approximate values, assign colors by role, document spacing, borders, radii, shadows, gradients, responsive behavior, and interaction states, then separate observed details from your recommended implementation choices. Return tokens, component rules, and an acceptance checklist without claiming access to any private design system.

Use Fudge with your AI agent to turn website references into a style handoff while you build.

Give Claude Code a narrow component brief with one section for each component family. For buttons, include height, horizontal padding, radius, border, text size and weight, icon spacing, primary and secondary variants, and hover, focus, pressed, disabled, and loading states. For cards, describe width behavior, internal padding, title and metadata hierarchy, image ratio, border or shadow treatment, and how cards stack on smaller screens.

For forms, document label placement, input height, placeholder color, border color, focus ring, validation message spacing, disabled treatment, and the difference between text fields, selects, and search controls. Include examples of long labels, errors, and empty values so the implementation does not only match the easiest case.

Ask for shared tokens before JSX or CSS. Then ask for a small set of representative components using those tokens. Compare each component with short text, long text, an icon, keyboard focus, and an error state. This exposes inconsistent padding and missing states early.

Label every item as observed, inferred, or proposed. Observed details are things you can directly verify, such as a visible type family, a repeated border treatment, or a consistent button height. Inferred details are careful interpretations, such as grouping two similar colors into one likely role. Proposed details are implementation decisions, such as naming tokens or adjusting a color for better readability.

Use language such as “the captured pages show” and “recommended for our implementation.” Avoid saying that a value is an official token unless you have access to source design files or documentation. Include screenshots or page links beside observations, but keep the brief focused on the behavior your team needs to reproduce.

Document deliberate differences too. You might keep compact spacing but use your own brand colors, or borrow a card hierarchy while changing the layout for your content. Tell Claude Code where adaptation is expected. This produces a more honest and maintainable result than asking for an exact copy, and it gives reviewers a clear way to challenge a recommendation without disputing what was visible.

Related questions

• Give Claude Code a Website's Gradients and Backgrounds
• Give Claude Code a Website's Color Roles
• Give Claude Code a Website's Image and Video Use
• Give Claude Code a Website's Border Radii and Shadows