On this page
The complete reference for the designtoken.md file format: structured design tokens in markdown that coding agents can parse deterministically.
A designtoken.md file is a structured markdown document containing a complete design token system: color palettes with full 50–900 scales, typography scales, spacing, elevation, border radius, and component token definitions, all formatted so coding agents can parse it deterministically.
Every designtoken.md file follows a strict section hierarchy. Each section is a level-2 or level-3 markdown heading that agents use for direct navigation.
Primary, Secondary, Tertiary, and Neutral color roles, each with a full 50–900 scale (10 steps). Followed by semantic color aliases for Success, Warning, Error, and Info that map to scale steps.
Font stack declaration (primary + fallbacks) and a full type scale table with 9 levels (from xs to 5xl) specifying size, weight, line-height, letter-spacing, and intended use for each level.
Named spacing tokens from 2xs to 3xl mapping to pixel values on a consistent progression (typically 4px base). Provides the spatial rhythm for padding, margins, and gaps.
Named radius tokens from sm to full, defining the curvature vocabulary. Ensures consistent rounding across buttons, cards, inputs, and other elements.
Named shadow tokens from sm to xl using CSS box-shadow syntax. Each level defines layered shadows for realistic depth progression.
Structured token sets for Buttons, Cards, Inputs, and Navigation. Each component defines background, text color, border, radius, padding, and state variants (hover, focus, disabled) using references to the primitive tokens above.
An ASCII or markdown-formatted reference card that shows the color palette, type scale, and spacing at a glance. Gives agents a condensed visual summary to validate their output against.
Tokens follow a dot-delimited naming pattern: category.role.variant. This flat namespace is readable by both agents and humans.
The designtoken.md format is designed for deterministic parsing. Agents navigate the file using markdown structure alone. No natural-language processing is needed.
Agents read the markdown headings (## and ###) to jump directly to the section they need. The heading hierarchy is fixed: the same sections always appear in the same order.
Color scales are defined as bullet lists with a consistent **Step:** #hex format. Agents match the bold marker to extract the step name and the hex value. No ambiguity, no variation.
The type scale is a standard markdown table with columns for size, weight, line-height, letter-spacing, and use. Agents parse the pipe-delimited rows and map each entry to a named token.
Component tokens use a key=value format within bullet lists. Each component section contains a flat list of properties that agents read as key-value pairs: background, text, border, padding, and state variants.
Natural-language design files require agents to infer intent from free-form text. designtoken.md eliminates inference: headings define navigation, formatting defines data types, and the fixed schema means agents always know exactly where to find each token.
A full designtoken.md file using a nature green theme. This example shows every required section and the exact formatting agents expect.
# Design Tokens
## Color Palette
### Primary (Nature Green)
- **50:** #F0F7F2
- **100:** #D4E8D9
- **200:** #B0D4B8
- **300:** #84BC91
- **400:** #5FA06D
- **500:** #4A7C59
- **600:** #3D6649
- **700:** #30503A
- **800:** #243B2B
- **900:** #18261D
### Secondary (Warm Sand)
- **50:** #FBF8F3
- **100:** #F3EDE0
- **200:** #E6D9C3
- **300:** #D4C0A0
- **400:** #BFA67D
- **500:** #A68B5B
- **600:** #8A7249
- **700:** #6D5A39
- **800:** #52432B
- **900:** #382D1D
### Tertiary (Sky Blue)
- **50:** #F0F7FB
- **100:** #D6EAF5
- **200:** #B0D5EB
- **300:** #82BCDD
- **400:** #5AA1CC
- **500:** #3E86B5
- **600:** #326D95
- **700:** #275575
- **800:** #1D3F57
- **900:** #132A3A
### Neutral
- **50:** #FAFAF9
- **100:** #F5F5F4
- **200:** #E7E5E4
- **300:** #D6D3D1
- **400:** #A8A29E
- **500:** #78716C
- **600:** #57534E
- **700:** #44403C
- **800:** #292524
- **900:** #1C1917
### Semantic Colors
- **Success:** #16A34A (Green-600)
- **Warning:** #D97706 (Amber-600)
- **Error:** #DC2626 (Red-600)
- **Info:** #2563EB (Blue-600)
## Typography
### Font Stack
- **Primary:** 'DM Sans', system-ui, sans-serif
- **Mono:** 'JetBrains Mono', monospace
### Type Scale
| Name | Size | Weight | Line-Height | Spacing | Use |
|---------|-------|--------|-------------|----------|------------------|
| xs | 12px | 400 | 1.5 | 0.01em | Captions, labels |
| sm | 14px | 400 | 1.5 | 0 | Secondary text |
| base | 16px | 400 | 1.6 | 0 | Body copy |
| lg | 18px | 500 | 1.5 | -0.01em | Lead paragraphs |
| xl | 20px | 600 | 1.4 | -0.01em | Card headings |
| 2xl | 24px | 700 | 1.3 | -0.02em | Section headings |
| 3xl | 30px | 700 | 1.25 | -0.02em | Page headings |
| 4xl | 36px | 700 | 1.2 | -0.03em | Hero titles |
| 5xl | 48px | 800 | 1.1 | -0.03em | Display text |
## Spacing Scale
- **2xs:** 4px
- **xs:** 8px
- **sm:** 12px
- **md:** 16px
- **lg:** 24px
- **xl:** 32px
- **2xl:** 48px
- **3xl:** 64px
- **4xl:** 96px
## Border Radius
- **sm:** 4px
- **md:** 8px
- **lg:** 12px
- **xl:** 16px
- **full:** 9999px
## Elevation / Shadows
- **sm:** 0 1px 2px rgba(74,124,89,0.06)
- **md:** 0 4px 12px rgba(74,124,89,0.10)
- **lg:** 0 8px 24px rgba(74,124,89,0.14)
- **xl:** 0 16px 48px rgba(74,124,89,0.18)
## Component Tokens
### Buttons
Primary:
- background=#4A7C59
- text=#FFFFFF
- border=none
- radius=8px
- padding=12px 24px
- hover:background=#3D6649
- focus:ring=0 0 0 3px rgba(74,124,89,0.3)
- disabled:opacity=0.5
Secondary:
- background=transparent
- text=#4A7C59
- border=1px solid #B0D4B8
- radius=8px
- padding=12px 24px
- hover:background=#F0F7F2
### Cards
- background=#FFFFFF
- border=1px solid #E7E5E4
- radius=12px
- padding=24px
- shadow=0 1px 2px rgba(74,124,89,0.06)
- hover:shadow=0 4px 12px rgba(74,124,89,0.10)
### Inputs
- background=#FFFFFF
- text=#1C1917
- border=1px solid #D6D3D1
- radius=8px
- padding=10px 14px
- focus:border=#4A7C59
- focus:ring=0 0 0 3px rgba(74,124,89,0.15)
- placeholder=#A8A29E
### Navigation
- background=#FFFFFF
- border-bottom=1px solid #E7E5E4
- height=64px
- link:color=#57534E
- link:hover=#1C1917
- link:active=#4A7C59
## Visual Reference
> This section describes how the token system looks when applied.
> For the interactive visual card, visit https://designtoken.md/generator
- **Overall feel:** warm and minimal
- **Primary color** reads as forest green, used for actions and emphasis
- **Neutral palette** provides light backgrounds with warm undertones
- **Typography** uses DM Sans for clean, modern readability
- **Spacing** is default, and the interface feels balanced
- **Corners** are subtly rounded, and the shape language is softhover:background.
The design.md format was introduced by Google Stitch (March 2026) as a way to capture design intent in a natural-language markdown file. It’s a great concept: a simple, human-readable file that describes your design system in prose. designtoken.md extends this concept with structured, deterministic token definitions that agents can parse without NLP inference.
Where a Stitch design.md describes colors by name (“Primary: Green #4A7C59”), a designtoken.md defines the full 50–900 scale for each role, giving agents every shade they need for hover states, surfaces, borders, and text contrast without guessing. Where design.md describes typography in a sentence, designtoken.md provides a 9-level type scale table with exact sizes, weights, line-heights, and letter-spacing. Where design.md mentions components in prose, designtoken.md defines structured key=value token sets with state variants.
| Dimension | design.md (Stitch) | designtoken.md |
|---|---|---|
| Color depth | 4–6 named roles | Full 50–900 scales + semantic aliases |
| Typography | 2–3 entries | Full 9-level type scale with responsive sizing |
| Components | Natural language descriptions | Structured token sets with state variants |
| Spacing | Mentioned in layout section | Named scale (4px–96px) with use annotations |
| Elevation | Not addressed | Shadow scale from sm to xl |
| Agent parsing | Requires NLP inference | Deterministic markdown: headings define navigation, formatting defines data types |
| Typical size | ~30 lines | ~150–200 lines |
Both formats serve the same purpose: giving coding agents design context. design.md is ideal for quick prototyping where approximate styling is fine. designtoken.md is for production work where agents need every token value specified explicitly.
designtoken.md is the static starting point. The Designless ecosystem extends it with runtime intelligence, reusable skills, and production-grade brand governance.
Use your designtoken.md file as a resource to generate a complete design system skill for Claude Code and Cowork, without writing a single line of code. The visual designer lets you drag-and-drop sections, preview output, and export a portable skill package that teaches your agent your design preferences.
Start building skills →Expression infrastructure that augments your coding agent with three runtime layers static tokens can’t provide:
Static tokens give your agent a dictionary. Expression infrastructure teaches it to write poetry.
See what happens when design tokens become a full expression system at runtime. Brand Capsules demonstrate the complete picture, from static tokens to living, agent-governed brand expression across every surface.
View Brand Capsules →A designtoken.md file is a structured markdown document containing a complete design token system — color palettes with full 50–900 scales, typography scales, spacing, elevation, border radius, and component token definitions — formatted so coding agents can parse it deterministically.
A typical design.md file contains 20–30 lines of natural-language color roles and font names. A designtoken.md file contains 150–200 lines of structured, production-ready token definitions with full color scales, type hierarchies, component states, and a visual reference section.
designtoken.md files work with any coding agent that reads project context files, including Claude Code, Cursor, GitHub Copilot, OpenAI Codex, and Google Gemini CLI.
Generate your token file at designtoken.md/generator, download it, and place it in your project root. Your coding agent will read it as context and use the token definitions to produce consistent, on-brand UI.
Yes. The generator is completely free with no signup required. Generate unlimited token files.
Expression infrastructure is the layer between a design system and an AI agent that actually composes. Static tokens give agents vocabulary (colors, fonts, spacing). Expression infrastructure adds three capabilities tokens can’t provide: Expression (runtime token resolution, layout adaptation, surface-aware rendering), Intelligence (brand guardrails, composition judgment, constraint negotiation, the “why this and not that” that human designers carry in their heads), and Evidence (version hashes, compliance logs, provable consistency). Tokens give agents a dictionary. Expression infrastructure teaches them to write poetry. Learn more →
Designless Studio is the production-grade expression infrastructure for AI agents. Start by generating a designtoken.md file here. That gives your agent static tokens. When you need runtime token resolution (where your design system updates across your app without regenerating files), brand guardrails that enforce consistency at machine speed, and an observability layer that proves compliance, that’s what Designless Studio does. It reads the same token vocabulary and serves it via API, augmented with intelligence and evidence layers. You can also use skill.design to turn your designtoken.md into a reusable design skill for Claude Code and Cowork without writing code.