Convert Website Design Details to CSS Custom Properties

A website-to-CSS custom properties workflow should turn observed design details into usable project variables without pretending to recover an official private design system. Inspect a page, group repeated values by role, label assumptions, and give your coding agent enough context to apply the result safely.

Start with semantic roles

Role-based names are easier to maintain than names tied to one appearance. A small starting layer might look like this:

Use names such as --color-text-muted rather than --gray-500. A role name tells components why a value exists and makes later changes safer. Treat the result as an observation from a particular page, state, and viewport. It does not prove the original site's private token names or cover every route, breakpoint, theme, or interaction state.

Inspect before creating variables

Collect only details that help implementation:

• Background, surface, text, muted text, border, link, success, warning, and danger roles.
• Font families, observed variants, heading and body sizes, weights, and line heights.
• Repeated spacing between sections, cards, controls, and text groups.
• Border widths, radii, shadows, gradients, and control states.
• Responsive changes to content width, columns, navigation, and card stacking.

The captured Linear reference provides a concrete typography observation: Inter at weight 400 for body copy, labels, navigation, and controls, and weight 500 for headings and emphasized interface text. Use that as a documented observation, then adapt the hierarchy to your own content and existing components.

Do not create a variable for every one-off value. Repeated colors, type settings, spacing steps, radii, and shadows deserve names. An unusual illustration offset or isolated decorative measurement usually belongs in its component.

Give your agent an implementation brief

Tell the agent where the variables belong, which files may change, and what must stay intact. For example: "Add the observed values as a small token layer in tokens.css. Use semantic names for color roles and spacing. Map existing components to the variables without changing their markup. Keep current brand colors unless explicitly approved. Add light and dark values only where both states were checked. Treat this as an observed reference, not the source site's official design system."

Review the output before applying it broadly. Check contrast for text, borders, and focus states; heading and body hierarchy; spacing consistency; button and form states; and narrow-screen wrapping. Compare a heading, paragraph, button, card, form field, and mobile layout with real project content. If a value works only for the reference page, keep it local instead of promoting it to a shared variable.

Use this in your AI agent

> Inspect the saved website reference and extract only observed design details that can be represented as CSS custom properties: color roles, typography families and weights, spacing steps, borders, radii, shadows, and responsive layout notes. Group repeated values by semantic role. Draft a clean tokens.css, explain which details were observed and which are assumptions, then show how to apply the variables to existing components. Do not claim this is the source site's official internal design system, and do not copy its branding or content.

Install Fudge for your AI agent to inspect references and pass the details into your coding workflow.

Create the smallest useful layer first. Begin with page background, surface background, primary text, muted text, border, accent, and focus colors. Then add the main font family, body size, heading sizes, common weights, and line heights. Finish with a short spacing scale, two or three radii, and one or two shadow levels if those values repeat.

A practical starter set includes --color-background, --color-surface, --color-text, --color-text-muted, --color-border, --color-accent, --font-sans, --font-size-body, --font-size-heading, --line-height-body, --radius-sm, --radius-md, and --space-1 through --space-6.

Add component-specific variables only when a pattern repeats. A shared control height or card padding may deserve a role, while a one-off hero offset probably does not. This keeps the token file readable and gives your coding agent fewer arbitrary values to manage.

Label the result as an observation from a specific captured page, state, and viewport. Separate directly identified details from assumptions. If a family and two weights were observed, state exactly that. Do not infer every weight, breakpoint, theme, or hidden interaction from one page.

Keep the original branding separate from reusable structure. You can describe a muted surface, compact type scale, or repeated card radius without presenting those details as official token names. Use semantic names in your project and document the source note beside the export.

Before applying variables everywhere, compare representative components: a heading and paragraph, a button in each available state, a card, a form field, and a narrow-screen layout. Check contrast and wrapping with real content. Values that work only for the reference page should remain local to that component.

Related questions

• Website to CSS Variables Converter for AI Coding Agents
• Website to Color and Font Tokens Converter for AI Coding Agents
• Convert a Website into a DESIGN.md File for AI Coding Agents
• Generate a Tailwind v4 theme from a live website