DESIGN.md: Wenn Design Tokens für KI-Agenten lesbar werden

Ein Entwickler, der eine Farbe falsch übernimmt, fragt irgendwann im Design-Review nach. Ein KI-Agent fragt nicht nach. Er nimmt einfach den nächstbesten Blauton, der ihm plausibel erscheint, und schreibt sauberen, funktionierenden Code drumherum. Genau da setzt DESIGN.md an.

Ich hatte im letzten Artikel über den Unterschied zwischen Design Tokens und Design Systems geschrieben und dabei bewusst offengelassen, wer diese Tokens eigentlich konsumiert. Meistens war die Antwort implizit: ein Mensch, der Komponenten baut. Genau diese Annahme kippt gerade. Wenn ich Claude Code, Codex oder vergleichbare Agenten UI-Code schreiben lasse, braucht das Design-System plötzlich ein Format, das nicht nur ein Mensch, sondern auch ein Agent zuverlässig lesen kann. Genau dafür hat Google Labs im April 2026 DESIGN.md quelloffen gestellt.

Das Problem, das DESIGN.md eigentlich löst

KI-Coding-Agenten sind mittlerweile erstaunlich gut darin, funktionierende Oberflächen zu bauen. Die Logik stimmt, die Komponenten rendern, die Interaktion funktioniert. Nur die Gestaltung bleibt dabei oft ein Ratespiel.

Ohne klare Referenz greift ein Agent auf das zurück, was er aus Trainingsdaten für „plausibles UI" hält. Das Ergebnis sieht selten schlecht aus, es sieht nur selten wie dein Produkt aus. Ein Blauton, der zufällig zur Konkurrenz passt. Ein Radius, der irgendwo zwischen zwei Designsystemen liegt. Nichts davon ist offensichtlich falsch, aber in Summe driftet die Marke bei jedem Prompt ein Stück weiter auseinander.

Genau dieses Problem kannte ich schon aus dem letzten Artikel, nur mit einer anderen Ursache: Dort fehlte eine zentrale Quelle der Wahrheit für Menschen. Hier fehlt sie für Agenten.

Zwei Schichten in einer Datei: Werte und Begründung

Der eigentliche Kniff von DESIGN.md ist simpel und trotzdem clever: Die Datei kombiniert maschinenlesbare Tokens mit menschenlesbarer Begründung, statt sich für eines von beidem zu entscheiden.

Im YAML-Frontmatter stehen die eigentlichen Werte, angelehnt an das W3C Design Token Format:

---
tokens:
  color:
    primary: "#132A13"
    accent: "#ECA400"
  dimension:
    radius-md: "8px"
  typography:
    heading: "Inter, 600"
---

Im Markdown-Body darunter steht das Warum:

## Primary
Gedecktes Waldgrün, bewusst kein reines Schwarz. Wirkt seriös,
ohne kalt zu wirken. Für Headlines und primäre Buttons.
 
## Accent
Warmes Amber als bewusster Kontrast zum Primary-Grün.
Nur für Call-to-Actions, nie für Fließtext oder Flächen.

Ein Agent liest den Frontmatter und bekommt exakte Werte. Ein Mensch liest den Fließtext darunter und versteht, warum diese Werte so gewählt wurden und wo die Grenzen ihrer Verwendung liegen. Eine reine Tailwind-Config oder ein Figma-Export kann das zweite nicht leisten, ein PDF-Styleguide wiederum nicht das erste.

Eine Familie von drei Dateien

DESIGN.md steht nicht allein. Google positioniert es als dritten Baustein neben zwei Formaten, die sich in der Agent-Welt bereits etabliert haben:

• AGENTS.md – wie sich der Agent grundsätzlich verhalten soll
• SKILL.md – welche konkreten Aufgaben er ausführen kann
• DESIGN.md – wie das Ergebnis visuell aussehen soll

Wer schon mit CLAUDE.md oder AGENTS.md arbeitet, kennt das Prinzip bereits: eine Datei, die am Anfang jeder Session automatisch geladen wird und Kontext liefert, den man sonst in jedem Prompt wiederholen müsste. DESIGN.md überträgt genau dieses Prinzip auf visuelle Identität.

Das Tooling: lint, diff, export

Google liefert DESIGN.md nicht als bloße Konvention, sondern mit einem npm-Paket, das drei Befehle mitbringt:

Der Kontrast-Check beim lint-Befehl ist der Teil, der mir am meisten auffällt. Eine reine Konfigurationsdatei prüft normalerweise nicht von sich aus, ob Primary-Text auf Primary-Hintergrund überhaupt lesbar bleibt. DESIGN.md macht Barrierefreiheit damit zu einer strukturellen Eigenschaft des Formats, nicht zu einer nachgelagerten Checkliste.

Der export-Befehl wiederum zeigt, dass DESIGN.md kein Ersatz für Tailwind oder das W3C-Format sein will, sondern eine Ebene darüber: ein Ausgangspunkt, aus dem sich andere Formate ableiten lassen, ohne die Werte doppelt pflegen zu müssen.

Wo das Format noch an Grenzen stößt

DESIGN.md liegt aktuell in Version 0.3.0 vor, also klar im Alpha-Stadium. Ein paar Lücken sind entsprechend real:

• Kein Dark Mode als eigenes Konzept. Die Zwischenebene aus semantischen Tokens, wie ich sie im letzten Artikel beschrieben habe, ist bislang nur rudimentär abgebildet.
• Keine Animationen und Timing-Werte. Bewegungssprache bleibt außen vor.
• Keine Responsive Breakpoints. Wie sich Tokens je nach Viewport verhalten, ist noch offen.

Der wichtigere Einwand ist aber ein grundsätzlicher: Eine Referenzdatei ist nur so gut wie ihre Aktualität. Eine veraltete DESIGN.md, die ein Agent unreflektiert für bare Münze nimmt, kann mehr Schaden anrichten als gar keine Referenz, weil sie mit der Autorität eines offiziellen Dokuments falsche Werte verbreitet.

Warum mich das mehr interessiert als ein weiteres Tool-Release

Ich sehe DESIGN.md nicht als fertiges Produkt, sondern als Signal für eine Verschiebung, die ich auch beim Führen von KI-Agenten beobachtet habe: Je mehr operative Arbeit an Agenten geht, desto wichtiger wird die Qualität der Referenzdokumente, die sie lesen. Nicht der Prompt im Moment entscheidet über das Ergebnis, sondern die Frage, ob überhaupt eine verlässliche, gepflegte Quelle existiert, auf die sich der Agent stützen kann.

Für Design Tokens heißt das konkret: Die semantische Ebene, über die ich im letzten Artikel geschrieben habe, bekommt mit Formaten wie DESIGN.md einen zweiten Adressaten. Bisher war sie für Entwickler gedacht, die Komponenten von Hand bauen. Jetzt wird sie zusätzlich zur Eingabe für ein System, das eigenständig Code produziert. Ob sich ausgerechnet DESIGN.md als Standard durchsetzt, kann ich nicht seriös vorhersagen. Dass Design-Referenzen maschinenlesbar werden müssen, sobald Agenten UI-Code schreiben, halte ich dagegen für ziemlich sicher.

Fazit

DESIGN.md macht aus einer für Menschen gedachten Design-Referenz eine, die zusätzlich von KI-Agenten zuverlässig gelesen werden kann, durch die Kombination aus YAML-Tokens und begründendem Fließtext. Google positioniert das Format bewusst neben AGENTS.md und SKILL.md, mit Lint-, Diff- und Export-Tooling im Rücken.

Als Alpha-Version fehlen noch Dark Mode, Animationen und Responsive Breakpoints, und die Gefahr veralteter Referenzdokumente bleibt real. Trotzdem lohnt sich ein Blick darauf, weil es eine Frage konkret beantwortet, die mit zunehmendem Agenten-Einsatz nur größer wird: Woher weiß ein Agent eigentlich, wie dein Produkt aussehen soll?

Bonus-Frage zum Mitnehmen: 👉 Würdest du deinem Coding-Agenten heute schon zutrauen, aus einer DESIGN.md allein eine neue Komponente markengerecht zu bauen?