DESIGN.md — The Design System File Your AI Agent Actually Reads

Your AI agent generates different UI every time because it has no memory of your design decisions. Different colors on Monday, different spacing on Tuesday, a completely new button style by Friday. You paste the same instructions into every prompt. It ignores half of them.

DESIGN.md fixes this. It's a single Markdown file — machine-readable design tokens in YAML front matter plus human-readable design rules in prose — that lives in your repo root. The agent reads it on every interaction. No repeated prompting. No drift. One file, consistent output. The official DESIGN.md specification is open-source (Apache 2.0), maintained by Google Labs, and has 17.2k stars on GitHub.

DESIGN.md is to visual design what AGENTS.md is to code conventions. Persistent context the agent checks every single time — not a one-off prompt that gets forgotten three messages later.

Created by

Google Labs

GitHub Stars

17.2k ★

License

Apache 2.0

Status

Alpha

The Problem

Before and after DESIGN.md

Without DESIGN.md

  • → Agent picks a random blue for buttons because you said "modern look"
  • → Font changes between prompts — Inter, then Poppins, then back to system fonts
  • → Spacing is 16px in one component, 20px in the next, 12px after a refactor
  • → Border radius: rounded one day, sharp the next
  • → You re-explain the design system every third prompt

With DESIGN.md

  • → Agent reads tokens: #B8422E for CTAs, always
  • → Public Sans Semi-Bold headlines, every single time
  • → 8px spacing scale with 4px half-step — no improvisation
  • → 4px corner radius across the board, as specified
  • → You describe what to build. The agent handles the how.

The difference isn't subtle. It's the difference between a design system and random CSS.

Skip the theory. Browse 461 ready-to-use DESIGN.md files →

View library

DESIGN.md Format

Two layers in one file

A DESIGN.md file has two parts: YAML front matter with design tokens, and a Markdown body with the reasoning behind them. Tokens are the source of truth for values. Prose tells the agent how to use those values — and when not to.

---
name: Heritage
colors:
  primary: "#1A1C1E"
  secondary: "#6C7278"
  tertiary: "#B8422E"
  neutral: "#F7F5F2"
typography:
  h1:
    fontFamily: Public Sans
    fontSize: 3rem
  body-md:
    fontFamily: Public Sans
    fontSize: 1rem
rounded:
  sm: 4px
  md: 8px
spacing:
  sm: 8px
  md: 16px
---

## Overview

Architectural Minimalism meets Journalistic Gravitas.
The UI evokes a premium matte finish.

## Colors

- **Primary (#1A1C1E):** Deep ink for headlines and core text.
- **Tertiary (#B8422E):** "Boston Clay" — the sole driver for interaction.

Feed this file to an agent and the result is predictable: deep ink headlines in Public Sans, warm limestone background, Boston Clay buttons. No guessing.

Tokens

DESIGN.md token schema

Tokens live as YAML front matter. The schema draws from the W3C Design Tokens spec — typed token groups, the {path.to.token} reference syntax for cross-linking values. Familiar if you've worked with Figma variables or Tailwind themes.

version: <string>          # optional, current: "alpha"
name: <string>
description: <string>      # optional
colors:
  <token-name>: <Color>
typography:
  <token-name>: <Typography>
rounded:
  <scale-level>: <Dimension>
spacing:
  <scale-level>: <Dimension | number>
components:
  <component-name>:
    <token-name>: <string | token reference>

Token types

Type Format Example
Color Any CSS color (hex, rgb(), oklch(), named, etc.) "#1A1C1E", "oklch(62% 0.18 250)"
Dimension number + unit (px, em, rem) 48px, -0.02em
Token Reference {path.to.token} {colors.primary}
Typography object with fontFamily, fontSize, fontWeight, lineHeight, letterSpacing see example above

Structure

8 sections of the DESIGN.md spec

Sections use ## headings. You can skip any of them, but those you include must follow this order — the LLM reads top to bottom, and sequence matters for context buildup.

1. Overview (alias: Brand & Style)

The big picture. What the product feels like — playful or serious, dense or spacious. Brand personality, target audience, emotional tone. This is the agent's fallback when no specific rule covers a decision.

## Overview
Architectural Minimalism meets Journalistic Gravitas.
The UI evokes a premium matte finish — a high-end broadsheet
or contemporary gallery.

2. Colors

Your palette with semantic roles attached. Convention: primary, secondary, tertiary, neutral. Each color gets a hex value, a descriptive name, and a usage rule. Without that semantic name, the LLM will happily use your error red as an accent — ask me how I know.

## Colors
- **Primary (#1A1C1E):** Deep ink for headlines and core text.
- **Secondary (#6C7278):** Sophisticated slate for borders, captions.
- **Tertiary (#B8422E):** "Boston Clay" — sole driver for interaction.
- **Neutral (#F7F5F2):** Warm limestone foundation.

3. Typography

Typography levels — most systems have 9 to 15. Tokens include fontFamily, fontSize, fontWeight, lineHeight, letterSpacing, fontFeature, and fontVariation. Agents need numbers. "Large font" means nothing to a machine. 48px does.

## Typography
- **Headlines:** Public Sans Semi-Bold — institutional, trustworthy.
- **Body:** Public Sans Regular at 16px — long-form readability.
- **Labels:** Space Grotesk — geometric precision. Uppercase, generous spacing.

4. Layout (alias: Layout & Spacing)

Layout strategy and spacing rules. Grid systems, margins, safe areas. Spacing tokens define the scale your project lives on — xs through xl, plus whatever custom levels make sense.

## Layout
Fluid Grid model for mobile, Fixed-Max-Width Grid for desktop (max 1200px).
Strict 8px spacing scale with 4px half-step for micro-adjustments.

5. Elevation & Depth (alias: Elevation)

How you show visual hierarchy. Shadow-based? Define spread, blur, color. Flat design? Explain what you use instead — borders, tonal layers, color contrast. The agent needs to know the rules of depth in your system.

## Elevation & Depth
Depth through Tonal Layers rather than heavy shadows.
Background uses soft off-white, primary content on pure white cards.

6. Shapes

The shape language. Rounded tokens — sm, md, lg, full — control border-radius on buttons, cards, inputs. Small detail, huge difference in perceived personality.

## Shapes
Architectural Sharpness. All interactive elements use minimal 4px corner radius.
Just enough softness to feel modern while maintaining a rigid aesthetic.

7. Components

Component tokens map a name to a set of properties — backgroundColor, textColor, typography, rounded, padding, size, height, width. Variants like hover, active, and pressed get their own entry. The agent picks the right variant for each state.

components:
  button-primary:
    backgroundColor: "{colors.tertiary}"
    textColor: "{colors.on-tertiary}"
    rounded: "{rounded.sm}"
    padding: 12px
  button-primary-hover:
    backgroundColor: "{colors.tertiary-container}"

8. Do's and Don'ts

Guardrails. LLMs respond remarkably well to negative instructions — telling them what NOT to do is often more effective than positive rules. This section prevents the agent from making your design generic.

## Do's and Don'ts
- Do use primary only for the single most important action per screen
- Don't mix rounded and sharp corners in the same view
- Do maintain WCAG AA contrast ratios (4.5:1 for normal text)
- Don't use more than two font weights on a single screen

Tools

DESIGN.md CLI tools

The @google/design.md package ships four commands: validate, compare, export, and inspect. Everything runs from npx — no global install.

lint — Validate structure

Checks broken references, WCAG AA contrast, orphaned tokens, section order, and missing typography.

npx @google/design.md lint DESIGN.md

diff — Compare versions

Detects token-level changes between two versions. Exit code 1 if regressions are detected.

npx @google/design.md diff DESIGN.md DESIGN-v2.md

export — Convert tokens

Exports tokens to Tailwind v3 theme config, Tailwind v4 CSS theme, or DTCG tokens.json (W3C Design Tokens Format).

npx @google/design.md export --format json-tailwind DESIGN.md
npx @google/design.md export --format css-tailwind DESIGN.md
npx @google/design.md export --format dtcg DESIGN.md
Format Output Description
json-tailwindJSONTailwind v3 theme.extend config object
css-tailwindCSSTailwind v4 @theme { ... } block with CSS custom properties
tailwindJSONAlias for json-tailwind (backwards-compatible)
dtcgJSONW3C Design Tokens Format Module

spec — Inject spec into prompts

Outputs the full format specification. Useful for injecting spec context into agent prompts.

npx @google/design.md spec
npx @google/design.md spec --rules --format json

Validation

Linting rules

The linter checks 9 rules against your DESIGN.md file. Each produces findings with a fixed severity — errors block, warnings advise, info just reports.

Rule Severity What it checks
broken-referrorToken references that don't resolve to any defined token
missing-primarywarningColors defined but no primary color exists
contrast-ratiowarningComponent backgroundColor/textColor pairs below WCAG AA minimum (4.5:1)
orphaned-tokenswarningColor tokens defined but never referenced by any component
token-summaryinfoSummary of how many tokens are defined in each section
missing-sectionsinfoOptional sections (spacing, rounded) absent when other tokens exist
missing-typographywarningColors defined but no typography tokens exist
section-orderwarningSections appear out of the canonical order defined by the spec
unknown-keywarningA top-level YAML key looks like a typo of a known schema key (e.g. colours: → colors:)

Programmatic API

Use the linter as a library

Need the linter inside your own tooling — CI pipelines, editor extensions, custom validators? It exports as a plain JavaScript library.

import { lint } from '@google/design.md/linter';

const report = lint(markdownString);

console.log(report.findings);       // Finding[]
console.log(report.summary);        // { errors, warnings, info }
console.log(report.designSystem);   // Parsed DesignSystemState

Why this format

Why DESIGN.md uses Markdown + YAML (not JSON)

Markdown is the format LLMs understand best — the bulk of their training data uses it. No special parsing instructions needed.

JSON tokens define values but not rules. You can't express "use primary only for the main CTA" in a tokens.json. DESIGN.md combines YAML tokens (exact values for machines) with Markdown prose (semantics and constraints for agents) in one file, zero build pipeline. The export command converts to Tailwind or DTCG when you need it downstream.

Criteria DESIGN.md Tokens (JSON) Style Guide
LLM-readable Native (trained on MD) Requires parsing Not readable
Machine-readable tokens Yes (YAML front matter) Yes (JSON) No
Human-readable Yes, no tooling Partial Yes
Versionable (Git) Yes Yes No (binary)
Context window Light (~2-5K tokens) Medium N/A
Build pipeline None (export available) Required N/A
Semantic rules Yes (Do's/Don'ts) No (values only) Yes
Token references Yes ({path.to.token}) Yes ($ref) N/A
Official CLI/linter Yes (@google/design.md) Varies N/A

Already using JSON tokens with a build pipeline? Keep them. DESIGN.md coexists — use export to bridge the two.

Get started

How to get a DESIGN.md file

Four paths, fastest to most hands-on.

1. Copy from the DESIGN.md library

Pick one by vertical or visual style, tweak the values for your project, done. The library has 461 documented files ready to grab.

2. Generate with the design-md skill

Point the skill at your codebase. It scans components, CSS variables, existing tokens — then extracts a structured DESIGN.md from the patterns it finds.

3. Export from Google Stitch

Already using Stitch? The export is native — same structure documented here, no extra steps.

4. Write manually

Follow the 8-section structure above. Validate with npx @google/design.md lint. Maximum control — you decide every token and every rule.

Naming

Recommended token names (Non-Normative)

These names show up across most design systems. Not required — but using them makes your DESIGN.md instantly familiar to anyone (or any agent) reading it.

Colors

primary, secondary, tertiary, neutral, surface, on-surface, error

Typography

headline-display, headline-lg, headline-md, body-lg, body-md, body-sm, label-lg, label-md, label-sm

Rounded

none, sm, md, lg, xl, full

Compatibility

DESIGN.md works with every AI coding agent

It's plain Markdown — any agent that reads project files can use it. No plugins, no integrations, no vendor lock-in. Drop the file in your repo root and point your agent config at it.

Agente Config Referência
Claude Code CLAUDE.md Siga regras visuais de @DESIGN.md
Cursor .cursor/rules/*.mdc Include do DESIGN.md
Kiro .kiro/steering/ Copiar DESIGN.md para steering
Windsurf .windsurfrules Referenciar DESIGN.md
Google Stitch UI nativa Import direto

Step-by-step setup: Claude Code · Cursor · Kiro · Windsurf · Google Stitch

FAQ

Frequently asked questions about DESIGN.md

What is DESIGN.md?

A Markdown file with YAML front matter that defines your project’s design system — colors, typography, spacing, components — in a format AI coding agents read natively. Claude Code, Cursor, Kiro all pick it up without extra configuration.

Does DESIGN.md replace Figma?

No. Figma is where you design visually. DESIGN.md is how you communicate those decisions to AI agents so they actually follow them. They complement each other.

Do I need design skills to use DESIGN.md?

Not to use a ready-made one. The designmd.app library has 461+ files you can copy and customize. The design-md skill can also generate one from your existing codebase.

Does it work with any AI agent?

Yes. Any agent that reads project files can use it — Claude Code, Cursor, Kiro, Windsurf, Google Stitch. It’s just Markdown. No special integration needed.

What's the difference between DESIGN.md and JSON design tokens?

JSON tokens define values but can’t express rules like "use this color only for the main CTA." DESIGN.md combines tokens (values) with prose (rules and intent) in one file. No build pipeline required. Export to Tailwind or DTCG when you need downstream tooling.

Can I use it in an existing project?

Yes. Drop the file in your project root, reference it in your agent’s config. It doesn’t touch existing code.

How do I validate my DESIGN.md?

Run npx @google/design.md lint DESIGN.md. It catches broken token references, WCAG AA contrast failures, orphaned tokens, section order violations, and missing typography.

How do I update it when the design changes?

Edit the file directly — it’s Markdown. Run npx @google/design.md diff before.md after.md to see token-level changes. Version with Git to keep history.

Does it work with React, Vue, Svelte?

DESIGN.md is framework-agnostic. It defines visual rules, not implementation details. The agent applies the rules regardless of your stack. Use export --format css-tailwind to generate a Tailwind v4 theme if needed.

What are Token References?

A way to cross-reference values using {path.to.token} syntax. Instead of repeating "#1A1C1E" in a component, you write {colors.primary}. Change the color once, everything updates. Same idea as CSS variables but inside the DESIGN.md schema.

Next steps

Browse the DESIGN.md library (461 files, organized by industry and style) or let the skill generate one from your existing codebase.

Setup guides by agent

Related articles