DESIGN.md — quand le design system devient lisible par les agents
Google Labs vient de publier DESIGN.md (15k+ stars en quelques semaines), un format de spécification pour décrire un design system à des agents de code. Le problème qu’il résout est concret : chaque nouvelle session, l’agent repart de zéro et régénère une UI inconsistante parce que le contexte design n’existe nulle part dans les fichiers qu’il lit.
La réponse est un fichier plain-text à la racine du projet. Deux couches : un front matter YAML pour les tokens (couleurs, typographie, spacing, composants avec leurs variantes hover/active), et un corps Markdown pour la rationale — pourquoi ces valeurs, comment les appliquer, ce qu’il ne faut pas faire.
---
name: Heritage
colors:
primary: "#1A1C1E"
tertiary: "#B8422E"
typography:
h1:
fontFamily: Public Sans
fontSize: 48px
fontWeight: 600
---
## Overview
Architectural Minimalism meets Journalistic Gravitas.
Le fond est limestone, les titres sont en encre profonde.
Un seul accent, "Boston Clay", strictement réservé aux actions primaires.La partie la moins évidente dans la philosophie du projet : les tokens ne sont que du contexte, pas des instructions de rendu. La prose fait le vrai travail. Une référence précise comme “un handout de cours magistral d’université des années 70” transporte automatiquement toutes les contraintes implicites que personne n’a besoin de lister.
Le CLI est utilisable dès maintenant :
# Lint — vérifie les références brisées, les ratios WCAG, les tokens orphelins
npx @google/design.md lint DESIGN.md
# Export vers Tailwind v4 (CSS variables @theme)
npx @google/design.md export --format css-tailwind DESIGN.md > theme.css
# Diff entre deux versions du design system
npx @google/design.md diff DESIGN.md DESIGN-v2.mdLe projet est en alpha, certaines sections (composants, motion) bougent encore. Le format accepte les tokens inconnus sans les rejeter, ce qui laisse de la place pour étendre sans attendre la spec. Un deepdive sur l’intégration dans un workflow agent IA arrive.