DESIGN.md Skill
DESIGN.md is Google's open spec (Apache-2.0, google-labs-code/design.md) for
describing a visual identity to coding agents. One file combines:
- YAML front matter — machine-readable design tokens (normative values)
- Markdown body — human-readable rationale, organized into canonical sections
Tokens give exact values. Prose tells agents why those values exist and how to
apply them. The CLI (npx @google/design.md) lints structure + WCAG contrast,
diffs versions for regressions, and exports to Tailwind or W3C DTCG JSON.
When to use this skill
- User asks for a DESIGN.md file, design tokens, or a design system spec
- User wants consistent UI/brand across multiple projects or tools
- User pastes an existing DESIGN.md and asks to lint, diff, export, or extend it
- User asks to port a style guide into a format agents can consume
- User wants contrast / WCAG accessibility validation on their color palette
For purely visual inspiration or layout examples, use popular-web-designs
instead. For process and taste when designing a one-off HTML artifact
from scratch (prototype, deck, landing page, component lab), use
claude-design. This skill is for the formal spec file itself.
File anatomy
Token types
Component property whitelist: backgroundColor, textColor, typography,
rounded, padding, size, height, width. Variants (hover, active,
pressed) are separate component entries with related key names
(button-primary-hover), not nested.
Canonical section order
Sections are optional, but present ones should appear in this order. The
linter flags out-of-order sections (section-order, warning) and duplicate
headings — consumers per the spec reject duplicates, so fix both before
returning the file.
- Overview (alias: Brand & Style)
- Colors
- Typography
- Layout (alias: Layout & Spacing)
- Elevation & Depth (alias: Elevation)
- Shapes
- Components
- Do's and Don'ts
Unknown sections are preserved, not errored. Unknown token names are accepted if the value type is valid. Unknown component properties produce a warning.
Workflow: authoring a new DESIGN.md
- Ask the user (or infer) the brand tone, accent color, and typography direction. If they provided a site, image, or vibe, translate it to the token shape above.
- Write
DESIGN.mdin their project root usingwrite_file. Always includename:andcolors:; other sections optional but encouraged. - Use token references (
{colors.primary}) in thecomponents:section instead of re-typing hex values. Keeps the palette single-source. - Lint it (see below). Fix any broken references or WCAG failures before returning.
- If the user has an existing project, also write Tailwind or DTCG
exports next to the file (
tailwind.theme.json,tokens.json).
Workflow: lint / diff / export
The CLI is @google/design.md (Node). Use npx — no global install needed.
All commands accept - for stdin. lint returns exit 1 on errors (warnings
alone exit 0). export exits 0 on a successful export regardless of lint
findings in the source — run lint separately to gate on those. Output is
JSON by default; parse it if you need to report findings structurally.
On Windows, the design.md bin name can collide with the .md file
association (silent no-op or the file opens in an editor). Use the dot-free
alias: npx -y -p @google/design.md designmd lint DESIGN.md.
Lint rule reference (the 9 rules, as of CLI 0.3.0)
broken-ref(error) —{colors.missing}points at a non-existent tokencontrast-ratio(warning) — componenttextColorvsbackgroundColorbelow WCAG AA (4.5:1)missing-primary(warning) — colors defined but noprimarytokenmissing-typography(warning) — colors defined but no typography tokensorphaned-tokens(warning) — color tokens never referenced by a componentsection-order(warning) — sections out of the canonical orderunknown-key(warning) — top-level YAML key that looks like a typo of a schema key (colours:→colors:); custom extension keys stay silenttoken-summary,missing-sections(info) — counts and absent optional sections
When the user cares about accessibility, call this out explicitly in your summary — WCAG findings are the most load-bearing reason to use the CLI.
Pitfalls
- Don't nest component variants.
button-primary.hoveris wrong;button-primary-hoveras a sibling key is right. - Hex colors must be quoted strings. YAML will otherwise choke on
#or truncate values like#1A1C1Eoddly. - Negative dimensions need quotes too.
letterSpacing: -0.02emparses as a YAML flow — writeletterSpacing: "-0.02em". - Section order matters even though the linter only warns. If the user gives you prose in a random order, reorder it to match the canonical list before saving — spec-compliant consumers expect it.
- Typography sub-property typos are silently dropped. As of CLI 0.3.0 a
typo like
fontwight:produces no finding and the value vanishes from exports — double-check sub-property names against the schema (fontFamily,fontSize,fontWeight,lineHeight,letterSpacing,fontFeature,fontVariation). version: alphais the current spec version (as of Jul 2026, CLI 0.3.0). The spec is marked alpha — watch for breaking changes.- Token references resolve by dotted path.
{colors.primary}works;{primary}does not.
Spec source of truth
- Repo: https://github.com/google-labs-code/design.md (Apache-2.0)
- CLI:
@google/design.mdon npm - License of generated DESIGN.md files: whatever the user's project uses; the spec itself is Apache-2.0.

