How to Extract Design Tokens for an AI Coding Agent

The most useful design-token handoff for an AI coding agent includes named colors, typography, spacing, borders, radii, shadows, and component rules, each tied to an observed use. Extract values first, then rewrite them as a small token file and implementation guide that an agent can apply without guessing.

Start with a token inventory

Review the reference and record:

• Colors: page background, raised surface, text, muted text, border, accent, success, warning, and danger.
• Typography: family, available weights, heading sizes, body size, line height, tracking, and casing.
• Spacing: common gaps between sections, cards, controls, labels, and icons.
• Shape: border width, radius scale, input height, button height, and shadow strength.
• Components: navigation, buttons, inputs, cards, badges, tables, dialogs, and empty states.
• Responsive behavior: what stacks, disappears, compresses, or changes order on smaller screens.

Record roles rather than isolated values. --color-text-muted tells an agent where a value belongs, while --gray-600 only describes how the value was named elsewhere.

The supplied Linear reference uses a near-black canvas, muted dividers, compact controls, and one cool accent. Its typography result identifies Inter at weights 400 and 500, with body copy, labels, navigation, headings, and emphasized interface text sharing a compact sans-serif treatment. Compare the captured examples before reusing the pattern.

Turn observations into a usable file

A practical handoff can start like this:

Do not fill the file with every value you can measure. Choose a coherent scale. Preserve differences only when they serve distinct roles, such as text, border, disabled content, and surface contrast.

Add a short DESIGN.md beside the tokens. State which token belongs to each common element, the maximum content width, preferred control height, and narrow-screen behavior. This prevents the agent from treating the token file as a bag of unrelated numbers.

Check the result before coding

Use four quick tests:

1. Role test: every token has a clear job and reasonable name.
2. Contrast test: primary text, muted text, borders, and accents remain distinguishable on their actual surfaces.
3. Reuse test: buttons, cards, and inputs share spacing and shape language unless the reference clearly differs.
4. Responsive test: the notes explain what happens when the reference no longer fits in one row.

Observed details are not necessarily an official internal design system. A captured page can show the values and patterns used on that page, but it cannot prove that those values are the owner-maintained source of truth. Label the handoff as an observed implementation unless you have that access.

Before implementation, separate facts from decisions. A measured color, repeated spacing value, or identified font can be listed as observed. A proposed token name, merged value, breakpoint, or component exception should be labeled as a recommendation. Ask the agent to preserve both lists so a later review can replace estimates without losing context.

Use this in your AI agent

> Inspect the saved website reference and extract an observed design-token handoff for implementation. Return named color roles, typography families and weights, spacing and sizing scales, borders, radii, shadows, responsive layout rules, and repeated component patterns. Separate measured or clearly observed details from recommendations, flag uncertain values, and write a concise DESIGN.md-style guide that explains which token each common component should use. Do not claim this is the site's official internal design system. Use Fudge with your AI agent.

Start with tokens that affect almost every screen and are easy for an agent to misuse:

1. Canvas and surfaces: page background, panel background, elevated surface, hover surface, and overlay surface.
2. Text roles: primary, secondary, muted, placeholder, inverse, and link text.
3. Borders and focus: default border, stronger divider, focus ring, and selected-state border.
4. Spacing: page padding, section gap, card padding, control gap, row gap, and icon gap.
5. Controls: input height, button heights, radius, internal padding, and disabled opacity.
6. Typography: body family, body size, line height, heading sizes, label size, and weights.
7. Data display: table row height, badge shape, status colors, code styling, and empty-state spacing.

Also document sidebar width, content max width, toolbar behavior, and the breakpoint where tables become scrollable or stacked. Capture one dense screen and one sparse screen to test whether spacing and surface tokens stay consistent. Name tokens by purpose, such as --surface-panel and --text-muted, rather than by the first raw color value you observe.

Give the agent a staged instruction. First ask it to summarize observed rules and list uncertainties. Next ask it to create the token layer and one representative component. Only after reviewing that result should it apply the tokens across the rest of the page.

Tell the agent which details are evidence and which are recommendations. Ask it to preserve named roles, reuse the spacing and radius scales, keep the typography hierarchy, and avoid inventing extra colors or one-off component styles. Require a comparison at the same viewport size, followed by a mismatch report grouped into color, type, spacing, shape, and layout.

Ask for a small exception list. If a hero panel, warning state, or data visualization intentionally breaks the normal rules, record that as a component-specific rule instead of changing the global token. Keep uncertain measurements marked as estimates so later review can replace them without hiding the original decision.

Related questions

• Extract Gradient Styles for an AI Coding Agent
• Extract Interaction Patterns for an AI Coding Agent
• Extract a Complete Design System for an AI Coding Agent
• Extract a Color System for Your AI Coding Agent