Extract a Website's Complete Design System

Contents

• [Use a repeatable capture order](#use-a-repeatable-capture-order)
• [Build a system map, not a screenshot list](#build-a-system-map-not-a-screenshot-list)
• [Convert the map into tokens and variants](#convert-the-map-into-tokens-and-variants)
• [Validate the result on representative screens](#validate-the-result-on-representative-screens)
• [Use this in your AI agent](#use-this-in-your-ai-agent)

To extract a website's complete design system, inspect repeated components and record the rules that connect them: typography, color roles, spacing, surfaces, borders, radii, shadows, layout, and interaction states. Finish with a token draft and a clear line between observed page details and assumptions about the site's internal system.

Use a repeatable capture order

Work from the elements that shape everything else to the details that appear only in specific components:

1. Page structure: canvas width, content columns, section rhythm, navigation, and major breakpoints.
2. Typography: families, weights, sizes, line heights, tracking, and casing.
3. Color: background, foreground, muted text, borders, accents, status colors, and gradients.
4. Spacing: page padding, section gaps, card padding, control gaps, and text spacing.
5. Components: buttons, inputs, cards, menus, tables, dialogs, and repeated content blocks.
6. States: hover, focus, active, selected, disabled, loading, error, and expanded states.

This order prevents a common mistake: extracting isolated colors or font sizes before understanding where they belong.

The captured Linear references below provide a concrete example. They show a near-black canvas, muted dividers, compact controls, a cool accent, and a compact sans-serif treatment using Inter. Compare both references to identify repeated choices, but do not assume that two captured pages reveal every page or the site's private design documentation.

Build a system map, not a screenshot list

Create one table for each category. A useful component table might look like this:

Record values only after checking more than one example. If every card uses the same radius and padding, that is a strong candidate for a shared token. If one promotional card differs, document it as a variant rather than changing the base rule.

For colors, name the role before the hex value. "Muted text" and "panel border" remain useful when the palette changes; a list of unnamed hex codes does not. Check contrast between text and its actual surface, including dark panels, overlays, and disabled controls.

Convert the map into tokens and variants

A practical first draft can be expressed in CSS or JSON:

Use placeholder values only as a structure for organizing your observations. Replace them with values you actually checked. Then define component variants such as primary, secondary, quiet, danger, compact, and disabled. A complete extraction is more useful when it explains how a button changes than when it lists only the default button.

If you want to move the result into a project, export the observed details to CSS, JSON, Tailwind v4, or DESIGN.md, then review the output manually. The export is a working handoff, not proof that you own an official internal design system.

Validate the result on representative screens

Test the extracted rules on four kinds of screens: a dense interface, a marketing section, a form-heavy view, and a mobile layout. Look for contradictions:

• Does the spacing scale still work when content wraps?
• Do muted colors remain readable on every surface?
• Do headings and controls keep the same hierarchy at narrow widths?
• Are cards and buttons consistent without making every section look identical?
• Are focus and error states visible, not just the default appearance?

If a rule fails in one place, make it a documented variant or return to the capture. Do not hide the conflict by adding an unexplained one-off value.

Use this in your AI agent

> Extract this website's complete observed design system. Inspect page structure, typography, colors, spacing, borders, radii, shadows, gradients, repeated components, responsive behavior, and visible interaction states. Organize the result into named tokens and component variants, include representative examples, identify contradictions across sections, and mark every value as confirmed, estimated, or still unknown. Return a practical CSS or JSON handoff, but do not claim it is the site's official internal design system or add unverified licensing facts.

Install Fudge for your AI agent

Capture the parts that repeat across the most screens first: page structure, typography, color roles, spacing, and core controls. These choices usually explain why the site feels consistent, and they give you a foundation for understanding less common components.

Start with the canvas and layout. Record the maximum content width, side padding, column behavior, section gaps, and how the navigation changes on smaller screens. Next capture type roles and color roles, not just isolated values. Then inspect buttons, inputs, cards, and navigation because these components expose shared height, padding, radius, border, and state rules.

Leave unusual illustrations, one-off promotional blocks, and complex animations for later. They can be important, but they should not distort the base system. The two Linear examples in this page are a useful comparison: repeated typography, surfaces, muted dividers, compact controls, and accent treatment are more valuable starting points than any single decorative detail.

As you work, keep a confidence column. Mark a rule as stronger when it appears in multiple sections and as provisional when it appears only once.

Try to use the extracted rules to rebuild a different screen from the same site. If the tokens explain the new screen without many unexplained exceptions, you likely captured a useful system. If every new component needs a new color, radius, spacing value, or font size, you probably copied one page instead.

Use a simple test set: one dense product screen, one marketing section, one form, and one narrow mobile view. Apply the same type scale, spacing steps, surface colors, and component variants to each. Watch for repeated relationships, such as the gap between a label and field, the contrast between primary and muted text, or the way headings separate from body copy.

Also check states. A page's default screenshot cannot tell you how focus, errors, disabled controls, menus, or loading states work. Mark those as unknown rather than inventing them.

Finally, keep the handoff honest. Call it an observed reference or implementation draft unless you have official documentation. That wording preserves the value of the work without implying ownership of an internal system you could not verify.

Related questions

• Extract a Website's Component Styles
• Extract a Website's Color System
• Extract a Website's Design Tokens
• Extract a Website's Border Radius Scale