DESIGN.md is now an open standard. Here's what that means for your brand.

A few days ago, Google Labs quietly published a repo called google-labs-code/design.md. It's a spec. A short one: a README, a schema, a handful of examples. It describes a file format for telling a coding agent what a brand looks like and why.

We've been building exactly this file for clients for the better part of a year. When I opened the spec, the interesting thing wasn't that it existed. It was how much of what we'd already written matched it: section names, token syntax, the separation between YAML values and prose reasoning. The shape was right.

This post explains what the standard is, why it matters that one exists, how a Taste Profile already conforms to it, and what that means for the files sitting in your repo (or soon to be).

What Google Labs actually shipped

The spec defines a single file, DESIGN.md, with two layers working together.

The YAML front matter holds machine-readable design tokens: colors, typography, shapes, layout, components. Values can be literal ("#2563EB") or token references ({colors.brand-accent}). A parser can read this and build a theme without ever touching the markdown.

The markdown body holds the prose: the philosophy, the constraints, the reasoning behind the values. It follows a canonical section order: Overview, Colors, Typography, Layout, Elevation & Depth, Shapes, Components, Do's and Don'ts. Sections beyond the first are optional, but the order is fixed so agents know where to look.

That's it. It's deliberately small.

The whole point of the format is that it sits at the intersection of two things that already exist: the W3C Design Tokens spec (values agents can apply) and Markdown (reasoning agents can read). Google Labs didn't invent a new format. They specified a convention for pairing the two.

Why one standard beats five proprietary ones

Before the spec dropped, every AI design tool had its own idea of "brand context."

Claude Design took Skills (Markdown + file pointers).
Cursor read loose .md files from your project root.
Lovable had per-project context fields.
v0 had an uploaded style guide.
Figma Make had its own internal representation.

They all solved the same problem: how do we give the model something persistent about this brand? And they all converged on roughly the same answer: some structured text in Markdown, plus some tokens.

What they didn't agree on was the exact shape. That meant every brand had to maintain five slightly different files, or pick one tool and write for it, or keep doing the paste-the-PDF dance at the start of every session.

A public spec collapses that. One file, one section order, one token reference syntax. If a tool reads DESIGN.md, it reads yours. If a new AI design tool launches next quarter and supports the standard, your file works there on day one.

This is the same move CSS variables were in 2015, or what JSON Schema did for API responses. Not a dramatic invention. Just the moment where a de facto pattern got written down.

The structural difference between the spec and what you might already have

If you've been writing brand docs for AI tools, you've probably been writing something that looks like the spec but isn't quite.

A common informal shape (the one we've used in our earlier post on DESIGN.md) is prose-first: Essence, Personality, Principles, Nevers, References, Tokens. It's a great writing prompt. It's not the Google Labs structure.

The reconciliation is straightforward: those prose sections live inside the spec's canonical sections, mostly in Overview and Do's and Don'ts. Your essence paragraph is the opening of Overview. Your principles become either principle statements in Overview or entries in Do's and Don'ts. Your nevers are exactly Don'ts. Your token reasoning threads into Colors, Typography, and Shapes.

In other words: the things you wanted to say are the same things. The spec just tells you where to put them so an agent knows where to look.

What the format actually unlocks

The narrow read is "one more file format." The real benefit is what that format lets you do.

Portability. Your DESIGN.md is not a Claude artifact or a Cursor artifact or a Stitch artifact. It's a file. When a new tool supports the standard (and they will, quickly), you drop the file in. No rewrite, no migration, no re-onboarding the model.
Durability. The spec sits in a public GitHub repo with versioning. The format will evolve, but the core structure (YAML tokens + canonical sections) is stable. What you write today keeps working.
Tooling. Once a format exists, people build tools for it. Validators. Visual editors. Converters to and from Figma variables, Tailwind themes, Style Dictionary. The last year's worth of "I wish someone would build X" becomes possible now that "X" has a schema to target.
No lock-in. You own the file. You can edit it in any text editor. You can put it on GitHub. You can move it to a new vendor, a new tool, a new team. There is no proprietary layer between you and your brand context.

That last one is the thing I care about most. Clients buying a Taste Profile aren't buying a subscription to our viewer. They're buying a repo of files that happen to be rendered at yourbrand.tasteprofile.io. The spec makes that portability explicit. If we disappeared tomorrow, your DESIGN.md would still work in Claude Design, Cursor, Stitch, and everything else that supports the standard.

How a Taste Profile conforms today

Here's what the design-system/ folder of a Taste Profile looks like (real excerpt, actual client):

---
version: alpha
name: ACME Corp
description: Capable but friendly. AI that feels like a helpful person, not intimidating software.
 
colors:
  purple-500: "#AD5DEF"
  purple-600: "#9332E0"
  # ...full Tailwind-style scale
  background: "{colors.base-white}"
  foreground: "{colors.base-black}"
  accent: "{colors.purple-500}"
 
typography:
  font-family-display: "Source Serif 4"
  font-family-body: "Inter"
  # ...type scale
 
shapes:
  radius-full: "9999px"
  radius-card: "1rem"
 
layout:
  spacing-scale: [0, 4, 8, 12, 16, 24, 32, 48, 64]
 
components:
  button:
    shape: "{shapes.radius-full}"
    elevation: "shadow-button"
---
 
## Overview
ACME is capable but friendly...
 
## Colors
ACME's identity rides on a single purple...
 
## Typography
Source Serif 4 for display, Inter for body...
 
## Layout
...

That's the spec, applied. YAML front matter with typed sections (colors, typography, shapes, layout, components) using token references. Markdown body in canonical order.

We didn't retrofit this after Google Labs published. We wrote it this way because the structure was the right structure. Google Labs just blessed it as the structure.

What you should do with yours

If you don't have a DESIGN.md yet: the spec is the right starting point. Don't write a prose brand guide and hope it works. Write against the schema from the first draft. The sections are named for you. The token syntax is specified. The Do's and Don'ts format is explicit. You skip six months of "is this too long, too short, the right shape" by writing to a format that already exists.

If you already have one in an informal shape: it's a two-hour edit, not a rewrite. Re-key your YAML into the spec's section names. Reorder your markdown headings into the canonical sequence. Keep your prose verbatim. The content is the content, and the spec only organizes it.

If you have a Taste Profile: you're already there. Your files conform. The only change in our delivery is that we now explicitly reference the spec in the files we ship, so any tool built against it recognizes your brand as a first-class citizen.

What comes next

Standards get adopted unevenly. Some tools will support DESIGN.md natively in weeks. The ones that were already reading loose Markdown brand files will just formalize the parser. Others will take a quarter. A few will hold out and ask you to paste their proprietary format instead.

That's fine. The whole value of an open spec is that you write once and the ecosystem comes to you. You don't have to pick the winning tool. You don't have to bet on Claude Design versus Stitch versus whatever launches in July. You give every tool the same file and let them compete on what they do with your brand, not on whether they can understand it.

Or write one yourself. The spec is right here. It's short. Your brand is worth the afternoon.

Part of our series on design systems for the AI era. See also: What is Claude Design, and how do you give it your brand? and DESIGN.md: the AI-era brand guide.