---
version: "1.0.0"
name: "<DESIGN SYSTEM NAME>"
description: "<One line an agent can use to decide whether this file is relevant.>"
colors:
  background: "#FFFFFF"
  foreground: "#0A0A0A"
  primary: "#0A0A0A"
  primaryForeground: "#FFFFFF"
  muted: "#F4F4F5"
  mutedForeground: "#71717A"
  border: "#E4E4E7"
  danger: "#DC2626"
typography:
  display:
    fontFamily: "<Family>, system-ui, sans-serif"
    fontSize: "3rem"
    lineHeight: "1.1"
    fontWeight: 400
  body:
    fontFamily: "<Family>, system-ui, sans-serif"
    fontSize: "1rem"
    lineHeight: "1.6"
    fontWeight: 400
rounded:
  sm: "4px"
  md: "8px"
  lg: "12px"
spacing:
  1: "4px"
  2: "8px"
  4: "16px"
  8: "32px"
---

<!--
  Destination: DESIGN.md at the repo root.

  DESIGN.md is a Google Labs format, Apache-2.0, still alpha. It is the only
  format in this pack with a typed schema and a real validator: the designmd
  CLI does lint, diff between two files, and export — including export to
  W3C DTCG, which makes it token-pipeline adjacent rather than a dead end.

  Know what it costs before you reach for it. Measured on its own for a
  simple screen, DESIGN.md ran about 92% more tokens than a tool call, with
  roughly 2.7x the run-to-run variance. The variance matters more than the
  average: a file pasted into context makes cost unpredictable, where a tool
  call makes it bounded.

  So the sensible policy, and the only published one we found, is to ship
  this file for portability — for the tools that have no access to your repo
  or your MCP server — and route real production work through the server.

  Canonical section order below: Overview, Colors, Typography, Layout,
  Elevation & Depth, Shapes, Components, Do's and Don'ts.
-->

# <DESIGN SYSTEM NAME>

## Overview

<What the system is for, and the one aesthetic decision that explains the
rest of it.>

## Colors

<Semantic roles first. Say what each role means, not what hue it is — an
agent told `primary` is blue will reach for blue directly.>

## Typography

<The scale, and when to use each step.>

## Layout

<Grid, container widths, the spacing rhythm.>

## Elevation & Depth

<Shadow scale, and what each level signifies.>

## Shapes

<Radius scale, and which components use which.>

## Components

<Per component: what it is for, and what it is not for.>

## Do's and Don'ts

- Do use semantic token roles.
- Don't hardcode a hex value. It will be correct in light mode and wrong in
  dark mode.
- Don't invent components. <List the names models most often invent here.>