DESIGN.md: Der Styleguide, den Ihre AI Agents wirklich lesen
Jedes Team, das Software mit AI ausliefert, läuft gegen dieselbe Wand. Der Agent schreibt Code, der funktioniert, aber er sieht nicht nach der eigenen Marke aus. Buttons haben einen leicht falschen Farbton. Überschriften bekommen die falsche Schriftstärke. Das Padding driftet von Session zu Session. Das Ergebnis stimmt, wirkt aber unverkennbar generisch.
Die Lösung war immer dieselbe: den Brand Guide in den Prompt kopieren, wieder und wieder, in jeder neuen Unterhaltung. PDFs helfen nicht. Figma-Links helfen nicht. Selbst eine gut geschriebene README.md deckt die visuelle Ebene selten detailliert genug ab.
DESIGN.md löst das. Und heute veröffentlichen wir ein kostenloses Tool, das eine solche Datei für jede Website in rund dreißig Sekunden erzeugt.
DESIGN.md-Generator ausprobieren →
Was DESIGN.md wirklich ist
DESIGN.md ist eine offene Spezifikation von Google Labs. Sie hält die visuelle Identität einer Marke in einer einzigen, maschinenlesbaren Markdown-Datei fest. Der Aufbau ist simpel: YAML-Design-Tokens für alles, was eine Maschine exakt treffen muss (Farben, Typografie, Abstände, Komponenten, Formen), dazu eine für Menschen lesbare Begründung für alles, was Interpretation braucht.
Die kanonische Datei hat acht Abschnitte, in dieser Reihenfolge:
- Overview – wie sich die Marke anfühlt, in einem Absatz
- Colors – primär, sekundär, neutral, Flächen
- Typography – Schriftfamilien, Größen, Stärken, Zeilenhöhen für jede Rolle
- Layout – Containerbreiten, Grid, Breakpoints
- Elevation & Depth – Schatten, Blur, die Regeln fürs Stapeln
- Shapes – Eckenradien, geometrische Sprache
- Components – Buttons, Cards, Eingabefelder als Token-Referenzen
- Do's and Don'ts – die Leitplanken
Token-Referenzen funktionieren so, wie man es erwartet: {colors.primary} in einer Komponentendefinition löst sich zum Wert am Anfang der Datei auf. Ändern Sie eine Variable, zieht das ganze System nach.
Dieser letzte Satz ist der eigentliche Kern.
Warum eine Markdown-Datei jedes andere Format schlägt
Designerinnen und Designer schreiben seit Jahrzehnten Brand Guidelines. Notion-Seiten, Figma-Bibliotheken, hundertseitige PDFs. Für Menschen funktioniert das alles. Für Agents funktioniert nichts davon.
Ein AI Agent, der Code schreibt, nimmt sich ein Projekt vor, sucht nach Kontext und legt los. Gelesen wird, was im Repo liegt. Ist Ihr Brand Guide eine Figma-Datei, ignoriert der Agent ihn. Ist er ein PDF, zieht der Agent vielleicht etwas Text heraus, verliert dabei aber die Struktur. Ist er ein Notion-Dokument, kopieren Sie die URL in jeden einzelnen Prompt.
Eine DESIGN.md im Wurzelverzeichnis Ihres Repos wird im ersten Zug jeder Session gelesen, von jedem Agent, der Markdown lesen kann. Also von Claude Code, Cursor, GitHub Copilot, Aider, Continue und allem anderen, das Ihren Dateibaum durchläuft. Keine Plugins, kein MCP-Server, keine Konfiguration. Nur eine Datei.
Der Agent hat jetzt strukturierte Tokens. Er kann bg-[#FA008C] schreiben, weil er gelesen hat, dass colors.primary gleich #FA008C ist. Er kann rounded-[12px] schreiben, weil er Ihre Radius-Skala gelesen hat. Er kann eine Button-Komponente bauen, weil Sie definiert haben, was button-primary ist. Das Problem der Brand-Drift verschwindet.
Der Generator, den wir gebaut haben
DESIGN.md von Hand zu schreiben ist nicht schwer, aber mühsam. Sie müssen die eigene Website inspizieren, Ihre CSS-Variablen auslesen, Ihre Schriftfamilien auflisten, Ihre Schattenwerte abgreifen und alles in das Format der Spezifikation übersetzen. Bei einer bestehenden Marke ist das reine Fleißarbeit.
Also haben wir ein Tool gebaut, das Ihnen das abnimmt. URL einfügen, DESIGN.md bekommen.
Zwischen Einfügen und Download passiert Folgendes:
Schritt 1 – Abrufen. Wir öffnen die Seite in einem Headless-Browser, warten, bis Schriften und Stylesheets sitzen, und machen einen Screenshot. Der Screenshot ist echt, gerendert, über die volle Seitenhöhe.
Schritt 2 – Signale extrahieren. Wir holen jedes Signal, das eine Maschine lesen kann: CSS Custom Properties, berechnete Styles auf Hero-Elementen, jede Google Font im Stylesheet, jede Tailwind-Utility-Klasse im DOM, das Favicon, die Logo-Kandidaten, die dominanten Farben im Screenshot.
Schritt 3 – Schlussfolgern. All das geht an ein LLM, mit einem Prompt rund um die offizielle Spezifikation. Das Modell rät nicht. Es entscheidet anhand der Werte, die es gerade gesehen hat, welche für die Marke stehen und welche nur Rauschen sind. Heraus kommt eine DESIGN.md in der kanonischen Reihenfolge der acht Abschnitte, mit verdrahteten Token-Referenzen.
Schritt 4 – Bearbeiten. Das Ergebnis landet in einem Live-Editor. Farbe anpassen, Schrift wechseln, Radius nachjustieren: Die Vorschau aktualisiert sich sofort. Wenn es passt, laden Sie die Datei herunter oder kopieren sie in die Zwischenablage.
Der ganze Ablauf dauert rund dreißig Sekunden für Seiten, die wir schon analysiert haben (wir cachen nach URL), und etwa eine Minute für neue.
Was das Ergebnis brauchbar macht
Beim Bauen haben wir ein paar Dinge gelernt, die so nicht in der Spezifikation stehen.
Unterscheidbarkeit der Marke zählt. Eine frühe Version des Prompts erzeugte Dateien, die technisch korrekt, aber langweilig waren. Jede Website bekam „modern, clean, minimalistisch“ in ihr Overview. Wir haben den Prompt umgeschrieben, damit das Modell benennen muss, was genau diese Marke von einer beliebigen SaaS-Landingpage unterscheidet. Das Overview ist heute der Abschnitt, den Nutzer am seltensten bearbeiten. Das sagt uns: Das Modell kommt der Sache näher.
Bei Komponenten summiert sich der Wert. Farben und Schriften lassen sich leicht von einem Screenshot abnehmen. Komponenten nicht. Ein button-primary, das auf {colors.primary}, {rounded.md} und die richtige Padding-Skala verweist, ist die Arbeitseinheit, die ein Agent beim Bauen einer UI tatsächlich erledigt. In den Komponenten-Abschnitt stecken wir mehr Model-Tokens als in alles andere.
Die Unknown-Content-Regel ist Ihr Freund. Die offizielle Spezifikation erlaubt Erweiterungen unter „unknown content“. Wir nutzen das für layout, elevation und logo: Felder, die nicht zu den kanonischen acht Abschnitten gehören, die aber jeder Agent, mit dem wir getestet haben, korrekt aufnimmt. Der Spezifikation strikt folgen, wo es zählt, und sie pragmatisch erweitern, wo es hilft.
Ab damit ins Wurzelverzeichnis
Der vorgesehene Workflow ist eine Zeile:
```
mv ~/Downloads/DESIGN.md ./DESIGN.md
```
Das ist das ganze Deployment. Wenn Sie Claude Code oder Cursor das nächste Mal in diesem Projekt öffnen, liest der Agent die Datei als Teil seines Startkontexts. Ab da ist jede UI, die er erzeugt, markenkonform, ohne dass Sie ihn daran erinnern müssen.
Wenn Sie weiter gehen wollen, verweisen Sie in Ihrer CLAUDE.md oder .cursorrules ausdrücklich darauf:
```
Visual style for this project is defined in DESIGN.md.
Use the design tokens exactly. Reference components by name.
```
Mehr Integration braucht es nicht.
Warum das bei Masumi liegt
Masumi ist das Zahlungsnetzwerk für AI Agents. Worauf wir hinarbeiten, dass Agents einander finden, Aufgaben delegieren und Zahlungen autonom abwickeln, funktioniert nur, wenn die beteiligten Agents Arbeit liefern, die zusammenhält. Ein Agent, der jede Session eine markenfremde UI ausliefert, ist noch kein KI-Mitarbeiter. Er ist ein Werkzeug mit schlechtem Gedächtnis.
Standards wie DESIGN.md machen aus Agents Mitarbeitende. Sie geben einem Agent eine verlässliche Referenz, so wie eine neue Kollegin am ersten Tag das Markenbuch bekommt. Je näher Agents an die Messlatte kommen, die wir für Menschen setzen, desto näher kommen wir der Agent Economy, für die dieses Protokoll gebaut ist.
Der Generator ist kostenlos, ohne Anmeldung, ohne Credits. Wenn er Ihrem Team eine Stunde spart und Ihre Agents aufhören abzudriften, freut uns das.