Design System Jump Starter: Reading the CSS of an inspiration site

Clients almost always arrive with an inspiration site. "We want it to feel like this one."

What happens next is familiar: Someone builds a mood board. Someone else eyedroppers a few colors. Then you open a blank Figma file and start guessing at the spacing scale.

The odd part is that the answer is already published. Every design decision on that site ships to the browser as CSS. The type scale, the spacing rhythm, the hover states, the disabled states. All of it is sitting in a stylesheet that anyone can request.

So I got curious. Could you read it directly and rebuild the system underneath, rather than approximating the surface?

The setup

Two MCP servers, with Claude Code in between.

Playwright drove a real browser at a pinned viewport, which matters more than it sounds. Without fixing the window size you can silently sample the tablet breakpoint and end up with a type scale that is subtly wrong everywhere and tons of components that differ only slightly in size. This would lead to an insane amount of bulk.

Figma's MCP handled the write side, creating variables, styles and component sets through the plugin API. Claude sat between them, parsing the stylesheets and resolving the token graph.

The first real obstacle showed up within minutes. Every stylesheet on the site was served from a CDN without CORS headers, so reading cssRules from inside the page threw on all seven bundles. This is common on large sites and it kills the approach entirely. Once you stop asking the browser and fetch the bundles directly, it starts to read the data you need.

What the stylesheet was hiding

The site did not just have colors. It shipped a complete, namespaced design system in its CSS. Roughly 900 custom properties, over 700 of them under a single prefix, already carrying semantic names like color-accent-surface-subdued and color-accent-border-quiet.

That naming pattern maps almost one to one onto Figma variable groups.

I had assumed I would need to infer meaning from usage. Which of these twelve grays is the border and which is the divider? That guesswork is the weakest part of any teardown, and it disappeared entirely. Their vocabulary was right there. On a smaller site built by a lesser dev team, this would be a more difficult task. I think it’s worth noting that I picked an enterprise site that I knew was built by a talented team.

Better still, the system was layered. Tokens did not point straight at hex values. They resolved through three levels: a component token points at a semantic token, which points at a primitive, which finally holds a hex value.

The middle layer is what makes theming work. Swap what the semantic token points at and every button, link and icon downstream follows. Flatten it and you have a palette.

There was a second axis too. Alongside light and dark, the system carried five accent scopes, each with its own gradient set. Figma allows one mode axis per collection, so those two dimensions had to live in separate collections. Because the accent tokens alias into the mode-aware layer rather than into raw primitives, a single token resolves against both at once. One name, ten possible values.

What landed in the file

630 variables across four collections. Light and dark throughout. Five accent themes. 28 text styles, 5 elevation styles, and 11 components at 82 variants. Every value bound to a token, with no hex codes sitting loose in a component.

A few things I did not expect.

• Their bold is 400. The system's bold weight resolves to 400 and its normal weight to 300, because the source family is a variable face carrying its own optical weight. Reproduce that literally and everything looks lighter than you expect until you understand why.
• Their palette has a duplicate. Two steps in the brand ramp hold the identical hex. Real drift, in a mature system, sitting in production. I left it in rather than tidying it, because the point was to reproduce what exists.
• The card is not a card. The DOM showed a four layer nesting: an outer frame with a background, an inner surface inset by exactly one pixel, and a content layer with a radius one pixel smaller than its parent. There is no CSS border anywhere. That one pixel gap is the border, which is how they support a gradient edge.

I would never have guessed that last one from the stylesheet, and a frame with a 1px stroke would have looked right while behaving differently. That is the argument for actually crawling the page rather than only parsing the CSS.

There is a lot more work that can be done to parse and curate down what is actually useful and what is repetitive.

What breaks

Not everything survives the trip, and being honest about the gaps is most of the value.

• Licensed type. The site runs a proprietary family. It does not exist in Figma and never will. Every text style got a substitute at the matching weight, with the original named in the description so the swap stays auditable. Sizes and metrics transferred exactly. Only the letterforms are approximate.
• Focus rings. CSS outline with outline-offset has no Figma equivalent. Outlines draw outside the box without affecting layout, and offset has no analog at all. I approximated with an outside stroke on a wrapper frame and documented the missing gap.
• Gradients. Figma gradient stops cannot bind to variables. So while every solid color follows the theme correctly, the gradients hold literal values and stay put when you switch modes.
• Absent states. The site declares an active state on exactly one component across its entire stylesheet. Not a single button has a pressed state. I could have invented one, but a gap in the source is information.

Is this actually useful?

The honest answer is that it worked this well because the source was mature. A site shipping a complete semantic token layer hands you the answer. Point this at a site with no CSS custom properties and the output degrades sharply, because now clustering and naming are inference again and every judgment call is yours.

But that is worth knowing in advance rather than discovering halfway through.

Where I think this genuinely earns its place is at kickoff. Instead of debating whether a client's inspiration site feels premium, you can show them the architecture underneath it. A kickoff meeting is often the start of expressing the meaning of process and is a good time to introduce design system based thinking.

That conversation is different from a mood board conversation. It moves a client from talking about aesthetics to talking about structure, which is where design systems thinking starts.

And it gives you something concrete to react against. Here is how they solved it. What should ours do instead?