Generate a Reusable Design Reference File from a Live Website

Contents

• [Start with a clear reference brief](#start-with-a-clear-reference-brief)
• [Record the details that affect reuse](#record-the-details-that-affect-reuse)
• [Choose the right file format](#choose-the-right-file-format)
• [Verify before treating it as a system](#verify-before-treating-it-as-a-system)
• [Use this in your AI agent](#use-this-in-your-ai-agent)

You can generate a reusable design reference file from a live website by capturing the page, separating observed details from assumptions, and exporting the result into a format your project can use. The most useful reference records typography, colors, spacing, layout patterns, components, and open questions instead of copying a page without context.

Start with a clear reference brief

Before inspecting the site, write down what the file needs to help someone do. A useful brief might say:

> Recreate the visual language of this product page for a new dashboard. Record fonts, type scale, colors by role, surface treatments, spacing patterns, borders, radii, shadows, responsive layout clues, and reusable component patterns. Mark anything that is only visible on one page.

This prevents the reference from becoming a loose collection of screenshots. It also gives you a way to decide whether a detail belongs in a shared design system or only in a single page composition.

Record the details that affect reuse

Use this checklist for each captured page:

• Typography: family, available variants, body weight, heading weight, approximate sizes, line heights, letter spacing, and casing.
• Color roles: page background, elevated surface, primary text, muted text, border, accent, success, warning, and destructive states where visible.
• Layout: page width, content columns, section spacing, navigation height, card proportions, alignment, and how the layout changes at smaller widths.
• Components: buttons, inputs, navigation items, cards, tabs, badges, tables, dialogs, and repeated controls.
• Surface treatment: border thickness, corner radius, shadows, gradients, dividers, overlays, and hover or active states when they can be observed.
• Content behavior: truncation, wrapping, image crops, video placement, and whether a section appears conditional or reusable.

Use the captured examples as a starting point for documenting typography and page structure. The supplied Linear evidence identifies Inter at weight 400 for body copy, labels, navigation, and controls, with weight 500 used for headings and emphasized interface text. Treat those as observed reference details, not universal rules for every project.

Choose the right file format

Pick the output based on who will use the reference:

For most teams, keep a human-readable DESIGN.md alongside machine-readable values. The Markdown file explains what each token means and where it was observed. The structured file makes it easier to search and reuse values without asking someone to interpret prose.

A good entry looks like this:

Avoid naming a color only by its hex value. A role such as text-muted remains useful when the palette changes; a bare value does not explain where it belongs.

Verify before treating it as a system

A live page can contain one-off marketing treatments, experiments, responsive exceptions, or styles inherited from a larger application. Compare at least two sections or pages when possible. Promote a detail into the reusable reference only when it repeats or clearly serves a shared role.

Use three confidence labels:

• Confirmed: repeated across pages or used by several components.
• Observed once: visible but not proven to be shared.
• Needs verification: inferred from appearance or incomplete states.

Also record what the file does not cover. For example, a public page may not reveal disabled states, error messages, keyboard focus, mobile navigation, or authenticated screens. Stating those gaps makes the reference safer for an AI coding agent to use.

Use this in your AI agent

> Inspect the captured website reference and generate a reusable design reference for my project. Separate confirmed repeated patterns from one-off page details. Record typography families and weights, color roles, spacing, layout structure, borders, radii, shadows, gradients, and component states. Then produce a concise DESIGN.md plus structured token values, with confidence notes and a checklist of details that still need verification. Use the observed Linear examples below only as inspiration, not as facts about my target website.

When you want an agent to repeat this workflow, install Fudge for your AI agent.

A design reference for an AI coding agent should include both values and meaning. Start with the project context, the pages or sections observed, and the parts that are confirmed versus uncertain.

Include:

• Font families, file or source notes when available, weights, sizes, line heights, and letter spacing.
• Semantic color roles such as background, surface, text, muted text, border, accent, success, warning, and danger.
• Spacing steps, container widths, column gaps, section padding, and common control heights.
• Border widths, radii, shadows, gradients, and overlay treatments.
• Component patterns for buttons, inputs, cards, navigation, tabs, tables, and alerts.
• Responsive behavior, including stacking, wrapping, hidden sections, and navigation changes.
• State details for hover, focus, selected, disabled, loading, empty, and error states when observed.
• A confidence note for every value that was inferred or seen only once.

Use semantic names instead of labels like blue-500 when the role is known. Include a short example for each component so the agent understands how tokens combine. Finish with an explicit verification list. That list helps the agent avoid inventing missing mobile behavior or treating a marketing illustration as a reusable interface pattern.

Create one source reference and two practical views of it. The source should be a DESIGN.md file with short sections for typography, colors, spacing, layout, components, states, responsive behavior, and known gaps. Add a small table for each token with its role, observed value, where it appeared, and confidence.

Then add structured values for the tools your team uses. For a Tailwind project, map semantic roles into theme variables. For a CSS-based project, use custom properties such as --color-surface and --space-section. For an AI coding agent, JSON is useful when you want predictable fields and easy updates.

Keep the files versioned with the project. When the website changes, capture the affected page again and update only the sections that changed. Do not silently replace uncertain values. Mark them as changed, confirmed, or still unverified.

Before sharing the file, run a short review:

1. Can a new engineer tell where each token belongs?
2. Are repeated patterns separated from page-specific decoration?
3. Are mobile and interaction gaps visible?
4. Can the values be pasted into the project without renaming every field?
5. Does the file explain what was observed rather than claiming ownership of the source site's internal design system?

That process produces a reference people can maintain instead of a snapshot that becomes misleading after the first implementation.

Related questions

• Generate structured JSON design details from a live website
• Generate a Tailwind CSS theme from a live website
• Website to Color and Font Tokens Converter for AI Coding Agents
• Convert Website Design Details to CSS Custom Properties