design.md: die Formatspezifikation, die Coding-Agenten eine dauerhafte visuelle Identität gibt

Eine von Google quelloffen gemachte Formatspezifikation (DESIGN.md), um Coding-Agenten die visuelle Identität einer Marke oder eines Produkts zu beschreiben, begleitet von einem CLI (lint, diff, export, spec), veröffentlicht als @google/design.md auf npm. Hinweis zur Begriffsklärung: Die Warteschlangenzeile „google-labs-code design” entspricht dem tatsächlichen Repository google-labs-code/design.md, dessen Name die Endung .md trägt.

Was es ist

google-labs-code/design.md ist keine Anwendung und kein Modell: Es ist eine Formatspezifikation, die definiert, wie die visuelle Identität eines Designsystems Coding-Agenten beschrieben wird, plus Werkzeuge, um sie zu validieren und zu exportieren. Das README fasst es zusammen als „eine Formatspezifikation zur Beschreibung einer visuellen Identität für Coding-Agenten. DESIGN.md gibt Agenten ein dauerhaftes, strukturiertes Verständnis eines Designsystems”.

Das Format kombiniert zwei Schichten in einer einzigen Klartextdatei:

YAML-Frontmatter — maschinenlesbare Design-Tokens (colors, typography, rounded, spacing, components), begrenzt durch ----Zäune am Dateianfang.
Markdown-Body — menschenlesbares Design-Rational, organisiert in ##-Abschnitten (zum Beispiel Overview, Colors, Typography).

Die zwei Schichten einer DESIGN.md: YAML-Token-Frontmatter und Markdown-Body mit Design-Rational

Die Tokens sind die normativen Werte; der Fließtext erklärt, warum diese Werte existieren und wie sie anzuwenden sind. Ein Agent, der eine DESIGN.md-Datei liest, erzeugt eine mit dieser Identität kohärente Oberfläche statt einer generischen „KI”-Oberfläche.

Neben der Spezifikation enthält das Repository das CLI (im Ordner packages/cli), veröffentlicht als @google/design.md auf npm, das DESIGN.md-Dateien validiert, vergleicht und exportiert und dabei JSON ausgibt, auf das Agenten reagieren können.

Ursprung

Das Format entstand innerhalb von Stitch, Google Labs’ „Design mit KI”-Produkt (Domain stitch.withgoogle.com). In Stitch erlaubt die Datei DESIGN.md, die Designregeln eines Projekts in ein anderes zu exportieren und zu importieren, sodass das Tool „die Überlegung hinter deinem Designsystem versteht” und markenkonforme Oberflächen erzeugt.

Die Open-Source-Veröffentlichung erfolgte am 21. April 2026 über den offiziellen Google-Blog, mit dem Post von Cassia Xu (Software Engineer) mit dem Titel „Stitch app’s DESIGN.md format is now open-source for designers”. Der offizielle Text erklärt die Motivation: Statt dass Agenten „die Absicht erraten”, „können sie genau wissen, wofür eine Farbe gedacht ist, und ihre Entscheidungen gegen WCAG-Barrierefreiheitsregeln validieren”. Der Post zitiert ein Video, in dem David East von Google Labs das Format erklärt. Das Repository wurde am 10. April 2026 auf GitHub erstellt, und die erste CLI-Version (0.1.0) wurde am 21. April 2026 auf npm veröffentlicht.

Das Format ist ausdrücklich als alpha-/Entwurfsversion markiert („open-sourcing the draft specification”); das README warnt, dass „das Format, das Token-Schema und das CLI sich in aktiver Entwicklung befinden” und mit Änderungen zu rechnen sei, während es reift.

Philosophie und Prinzipien

Die Datei PHILOSOPHY.md des Repositorys erklärt die Prinzipien unmissverständlich:

Fließtext, nicht Tokens, ist der Fokus. „Die Qualität eines generierten Designs hängt weniger von der Präzision seiner Werte ab als davon, wie klar die Absicht beschrieben wird.” Das Dokument erklärt, es „akzeptiert oder empfiehlt generell keine Token-Anforderungen in der Spezifikation”: Tokens sind Kontext, der dem Fließtext als Referenz dient, keine Rendering-Anweisungen.
Eine konkrete Referenz ist mehr wert als eine Liste von Adjektiven. Ein Verweis auf „eine Vorlesungsmitschrift eines Graduiertenseminars der 70er-Jahre in der Tradition einer alten Universität” evoziert eine ganze Welt (einfarbige Tinte, großzügige Ränder, Serif in Lesegröße, Abwesenheit von Dekoration); „modern, sauber, vertrauenswürdig, premium” evoziert nichts Konkretes und erzeugt generische Ausgaben. „Adjektive beschreiben eine Region; eine konkrete Referenz beschreibt einen Punkt.”

Philosophie des Formats: eine konkrete Referenz gegenüber generischen Adjektiven, die nichts Spezifisches evozieren

Negative Einschränkungen. Ein benanntes Objekt trägt seine Einschränkungen automatisch: Ein Modell weiß, was eine Vorlesungsmitschrift ist und was nicht (sie glänzt nicht, verwendet keine Farbverläufe). „Das Benennen des Objekts benennt seine Einschränkungen, genauso wie das Benennen eines Hundes dem Modell sagt, dass Hunde nicht miauen.” Eine lange Liste von „Nicht-Tun”-Regeln ist meist ein Zeichen dafür, dass die Beschreibung zu vage war, um sie zu tragen.
Das Format wächst durch seine Nutzer, nicht durch seine Spezifikation. Die Spec definiert das universelle strukturelle Minimum (einen Namen und eine kleine Kategorienmenge: Farben, Typografie, Abstand, Rundung, Komponenten). Alles andere — Bewegung, Ikonografie, Erhebung, Großschreibung, Absatzmaß — definiert jedes System selbst. Der Linter akzeptiert jeden Schlüssel, jeden Abschnitt, jede Struktur; „es war keine Spec-Änderung nötig, weil die Tokens selbst Kontext sind, keine Anweisung”.

Wie es funktioniert

Dateistruktur und Token-Schema

Eine DESIGN.md hat zwei Schichten. Das YAML-Frontmatter deklariert Tokens nach diesem Schema (laut docs/spec.md):

version: <string>          # optional, aktuell "alpha"
name: <string>
description: <string>      # optional
omitted: <string[] | OmittedSection[]>  # absichtlich ausgelassene Abschnitte
colors:
  <token-name>: <Color>
typography:
  <token-name>: <Typography>
rounded:
  <scale-level>: <Dimension>
spacing:
  <scale-level>: <Dimension | number>
components:
  <component-name>:
    <token-name>: <string | token reference>

In der Spec verifizierte Token-Typen:

Typ	Format	Beispiel
Color	jede CSS-Farbe (Hex, `rgb()`, `oklch()`, benannt usw.)	`#1A1C1E`, `oklch(62% 0.18 250)`
Dimension	Zahl + Einheit (`px`, `em`, `rem`)	`48px`, `-0.02em`
Token Reference	`{path.to.token}`	`{colors.primary}`
Typography	ein Objekt mit `fontFamily`, `fontSize`, `fontWeight`, `lineHeight`, `letterSpacing`, `fontFeature`, `fontVariation`	siehe Beispiel im README

Das Token-System ist vom W3C-Design-Tokens-Format inspiriert (designtokens.org), von dem es typisierte Token-Gruppen und die Referenzsyntax {path.to.token} übernimmt.

Tokens als lebendiges System: Farben, Typografie, Abstand und Rundung, verbunden in einer Konstellation

Kanonische Reihenfolge der Abschnitte

Abschnitte nutzen ##-Überschriften und müssen, wenn vorhanden, in dieser Reihenfolge erscheinen (mit ihren Aliasen):

Overview (Alias Brand & Style)
Colors
Typography
Layout (Alias Layout & Spacing)
Elevation & Depth (Alias Elevation)
Shapes
Components
Do’s and Don’ts

Verhalten bei unbekanntem Inhalt

Szenario	Verhalten
Unbekannte Abschnittsüberschrift	Wird beibehalten; kein Fehler
Unbekannter Farb-Token-Name	Wird akzeptiert, wenn der Wert gültig ist
Unbekannter Typografie-Token-Name	Wird als gültige Typografie akzeptiert
Unbekannte Komponenteneigenschaft	Wird mit Warnung akzeptiert
Doppelte Abschnittsüberschrift	Fehler; die Datei wird abgelehnt

Das CLI

Das CLI (packages/cli, veröffentlicht als @google/design.md) stellt vier Befehle bereit. Alle akzeptieren einen Dateipfad oder - für stdin und geben standardmäßig JSON aus.

Befehl	Funktion
`lint`	Validiert die strukturelle Korrektheit einer `DESIGN.md`. Exit-Code `1` bei Fehlern, sonst `0`.
`diff`	Vergleicht zwei `DESIGN.md`-Dateien und meldet Änderungen auf Token-Ebene. Exit-Code `1`, wenn Regressionen erkannt werden.
`export`	Exportiert Tokens in andere Formate (`json-tailwind`, `css-tailwind`, `tailwind`, `dtcg`).
`spec`	Gibt die Formatspezifikation aus (nützlich, um Spec-Kontext in Agenten-Prompts einzuspeisen). Optionen `--rules`, `--rules-only`, `--format markdown\|json`.

Das CLI in Aktion: die vier Befehle lint, diff, export und spec gegen eine DESIGN.md-Datei

Der Linter führt elf Regeln (mit festen Schweregraden) gegen die geparste DESIGN.md aus: broken-ref (Fehler), missing-primary, contrast-ratio (WCAG AA, 4,5:1), orphaned-tokens, missing-typography, section-order, unknown-key (erkennt Tippfehler wie colours: → colors:), token-like-ignored (Warnungen); sowie token-summary, missing-sections, omitted-rules (Information).

Linter-Validierung: elf feste Regeln, einschließlich der WCAG-AA-Kontrastprüfung und der kanonischen Abschnittsreihenfolge

Es gibt außerdem eine programmatische API, um den Linter als Bibliothek zu nutzen:

import { lint } from '@google/design.md/linter';
const report = lint(markdownString);
console.log(report.findings);      // Finding[]
console.log(report.summary);       // { errors, warnings, info }
console.log(report.designSystem);  // geparster DesignSystemState

Token-Interoperabilität

Der Befehl export konvertiert Tokens zu:

Tailwind-v3-Konfiguration (JSON) — --format json-tailwind (Alias tailwind): ein theme.extend-Objekt für tailwind.config.js.
Tailwind-v4-Theme (CSS) — --format css-tailwind: ein @theme { ... }-Block mit den CSS-Variablen-Namensräumen von Tailwind v4 (--color-*, --font-*, --text-*, --leading-*, --tracking-*, --font-weight-*, --radius-*, --spacing-*).
DTCG tokens.json (W3C-Design-Tokens-Modulformat) — --format dtcg.

Das Ökosystem

Das Repository ist die offizielle Spezifikation, aber darum herum ist ein Ökosystem aus Sammlungen, Generatoren und Community-Tools gewachsen. Dies konnte in dieser Recherche verifiziert werden (Sterne laut GitHub-API vom 26. August 2026):

Sammlungen und Kataloge von DESIGN.md:

VoltAgent/awesome-design-md — eine Sammlung von DESIGN.md-Dateien, geparst aus den Designsystemen populärer Marken; „lege eine in dein Projekt und lass Coding-Agenten eine passende Oberfläche erzeugen”. 110.550 Sterne, 12.586 Forks. Erstellt am 31. März 2026; seine Website ist getdesign.md.
scroobius-pip/fudge-design-md — DESIGN.md-Guides, generiert aus echten, von Fudge erfassten Website-Referenzen. 75 Sterne.

Karte des DESIGN.md-Ökosystems: Community-Sammlungen, Generator-Seiten, Chrome-Erweiterungen und Schwester-Repos von Google

Zugehörige Seite und Umfrage:

getdesign.md — ein DESIGN.md-Katalog für Coding-Agenten (300+ Seiten im Katalog) und ein DESIGN.md-Generator. Veröffentlicht die Umfrage „State of DESIGN.md 2026” (basierend auf 64.000+ Onboarding-Antworten über 11 Wochen; die Seite behauptet 102.000+ GitHub-Sterne und 1.000.000+ DESIGN.md-Downloads — das sind Behauptungen der Seite selbst, keine unabhängigen Messungen).

Schwester-Repositories derselben Organisation google-labs-code (dasselbe Team hinter Stitch/Jules):

google-labs-code/stitch-skills — eine Agent-Skills-Bibliothek, konzipiert für den MCP-Server von Stitch. 8.187 Sterne.
google-labs-code/stitch-sdk — erzeugt UI-Bildschirme aus Textprompts und extrahiert deren HTML. 1.787 Sterne.
google-labs-code/jules-awesome-list — Prompts für den Jules-Agenten. 3.158 Sterne.
google-labs-code/jules-action (227), jules-sdk (124), jules-skills (90), action-setup (21).

Chrome-Erweiterungen zum Erzeugen von DESIGN.md (erwähnt in HN-Threads):

„AI Design Taste – Design.md Generator” (Chrome-Web-Store-ID peclkdlolmcclhhgpoehpikgknbmkknc).
„Design.md Style Extractor” (ID ogpdnchdjiibhobphelbbkemnnemkfma), der Stile extrahiert und DESIGN.md-Dateien erzeugt.

Referenzstandards: Das Format stützt sich auf das W3C-Design-Tokens-Format (designtokens.org), in das es sowohl konvertiert (export --format dtcg) als auch aus dem es konvertiert.

Offizieller / halboffizieller Status

Das Repository hat Vendor-offiziellen Status: Es ist unter Googles Organisation google-labs-code auf GitHub gehostet, und das Format wurde am 21. April 2026 von Google Labs als Stitchs Entwurfsspezifikation quelloffen gemacht. Die offizielle Dokumentationsseite lebt unter stitch.withgoogle.com/docs/design-md/specification.

In der Praxis bedeutet das:

Es ist die Referenzspezifikation für das Format DESIGN.md, direkt genutzt von Googles kommerziellem Tool Stitch.
Es ist als alpha/Entwurf markiert, nicht als fertiger Standard: Das README erklärt „expect changes to the format as it matures”, und die Spec zeigt version: alpha.
Es ist kein Konsortiumsstandard: Es lässt sich inspirieren vom W3C-Design-Tokens-Format und exportiert nach tokens.json (DTCG), ist aber keine W3C-Norm. Seine Offizialität ist die eines Anbieters (Google), nicht eines externen Gremiums.

Schnellstart-Anleitung

Installation und erster Start

Das Paket ist @google/design.md auf npm.

npm install @google/design.md

Unter Windows, falls die Shell @ besonders behandelt (PowerShell), lohnt sich das Anführungszeichen:

npm install "@google/design.md"

Oder es einfach immer direkt aus dem öffentlichen Register ausführen (die einfachste Form):

npx @google/design.md lint DESIGN.md

Beim ersten Lauf reicht eine DESIGN.md-Datei (YAML-Frontmatter + Markdown-Body). Zum Beispiel liefert npx @google/design.md lint DESIGN.md JSON mit findings (jeweils mit severity, path, message) und einer summary (errors, warnings, infos).

Übliche Workflows

Um eine DESIGN.md zu validieren (defekte Token-Referenzen, WCAG-Kontrastprobleme, falsch geordnete Abschnitte erkennen): npx @google/design.md lint DESIGN.md ausführen; das Ergebnis ist JSON mit findings und summary. Exit-Code 1 bei Fehlern.
Um Regressionen zwischen zwei Versionen eines Designsystems zu erkennen: npx @google/design.md diff DESIGN.md DESIGN-v2.md; liefert tokens (added/removed/modified pro Abschnitt) und findings mit delta, plus ein regression-Flag. Exit-Code 1 bei Regressionen.
Um Tokens nach Tailwind v3 zu exportieren (JSON-Konfiguration für tailwind.config.js): npx @google/design.md export --format json-tailwind DESIGN.md > tailwind.theme.json.
Um nach Tailwind v4 (CSS) oder nach DTCG zu exportieren: npx @google/design.md export --format css-tailwind DESIGN.md > theme.css oder ... --format dtcg DESIGN.md > tokens.json.
Um die Spec in einen Agenten-Prompt einzuspeisen: npx @google/design.md spec (mit --rules, um die Tabelle der Lint-Regeln hinzuzufügen).

Wesentliche Konfiguration

Das YAML-Frontmatter der DESIGN.md — die normativen Tokens (colors, typography, rounded, spacing, components). Das ist, was der Linter validiert und export serialisiert.
Der Schlüssel name (erforderlich) und version (optional, alpha) — identifizieren das Designsystem.
omitted — eine Liste absichtlich ausgelassener Abschnitte (z. B. omitted: [spacing] oder {section: rounded, reason: "..."}); unterdrückt Linter-Warnungen für fehlende Abschnitte.
Die Beispieldateien des Repositorys (examples/atmospheric-glass, examples/paws-and-paths, examples/totality-festival) — jede liefert DESIGN.md + tailwind.config.js + design_tokens.json als Startvorlage.
Der konsumierende Agent-Harness (Claude Code, Gemini CLI, Stitch usw.) — die DESIGN.md wird im Projekt platziert, und der Agent liest sie als Referenz für die visuelle Identität.

Häufige Fallstricke und Lösungen

Windows: Die design.md-Bin öffnet den Markdown-Editor. Das Suffix .md im Namen der Bin kollidiert mit Windows’ Markdown-Dateizuordnung. Im README dokumentierte Lösung: den punktfreien Alias designmd verwenden → npx -p @google/design.md designmd lint DESIGN.md. In package.json-Skripten (nicht über npx) wird stets designmd empfohlen.
npm error ENOVERSIONS („No versions available for @google/design.md”). Bedeutet fast immer, dass npm nicht das öffentliche Register abfragt (eine .npmrc mit angepasstem registry=, ein nicht synchronisierter Unternehmens-Spiegel, oder ein falsch konfiguriertes @google:registry). Mit npm config get registry prüfen (sollte https://registry.npmjs.org/ sein) und, falls ein 404 gecacht wurde, npm cache clean --force.
Aufgespaltene export-Exit-Codes (behoben in 0.4.0). Seit 0.4.0 liefert ein erfolgreicher Export immer den Exit-Code 0 (entkoppelt von den Linter-Warnungen des Quelldokuments); zuvor verhinderte dies, dass gültige Builds Pipeline-Gates passierten.
Linter-Abstürze durch verschachteltes oder Nicht-String-YAML (behoben in 0.3.0). Verschachtelte Deklarationen wie colors: { background: { light: '#fff' } }, numerische Werte in spacing (unit: 8) und boolesche Skalare in Komponenteneigenschaften brechen den Linter nicht mehr.
Eine nicht existierende Datei (behoben in 0.4.0). Das Lesen einer nicht vorhandenen oder unlesbaren DESIGN.md gibt jetzt eine saubere Meldung + strukturiertes JSON mit Exit-Code 2 aus, statt eines Stack-Traces.

Integrationen und Migration

Tailwind. export --format json-tailwind (v3) und --format css-tailwind (v4) geben direkt Tailwind-Theme-Konfigurationen aus, was erlaubt, DESIGN.md als Token-Quelle zu nutzen und das Theme der App abzuleiten.
DTCG / Figma / Style Dictionary. export --format dtcg erzeugt tokens.json, kompatibel mit dem W3C-Design-Tokens-Format und mit Token-Pipelines (Figma, Style Dictionary usw.).
Coding-Agenten. Die DESIGN.md wird als Referenzdatei im Repository des Projekts platziert; jeder Agent (Claude Code, Gemini CLI, Stitch, Cursor) liest sie, um visuelle Kohärenz über Generationen und über Tools hinweg zu wahren. npx @google/design.md spec erlaubt, die Spec als Kontext einzuspeisen.
Programmatische API. Die Funktion lint() von @google/design.md/linter erlaubt, die Validierung in CI oder eigene Tools zu integrieren.
Migration. Da es sich um ein Beschreibungsformat handelt (kein Zustandsformat), bedeutet „Migrieren” zu DESIGN.md, das Designsystem in der Datei zu beschreiben; aus einem bestehenden Tailwind-Theme oder tokens.json lässt sich das Frontmatter rekonstruieren, und dorthin lässt sich exportieren. Das Repository erklärt keinen automatischen Konvertierungsassistenten von anderen Tools.

Zahlen zum Repo

Messung: 26. August 2026, GitHub-API.

Metrik	Wert
Sterne	27.514
Forks	2.285
Abonnenten (Watchers)	171
Von der API angegebene offene Issues	41
Commits (Hauptbranch)	62
Hauptsprache	TypeScript
Lizenz	Apache-2.0
Erstellung	10. April 2026
Letzter Push	27. Juli 2026
Letztes Release	0.4.0 (27. Juli 2026)

Wichtigste Contributor nach Beitragszahl (GitHub-API): davideast (16), rmyndharis (9), xkxx (6), mvanhorn (4), Emp1500 (3), SyedaQurratAI (2), tejas100 (2).

npm-Downloads des Pakets @google/design.md (npm-API, 26. August 2026): 138.138 Downloads in der letzten Woche (19.08.2026 bis 25.08.2026) und 629.805 im letzten Monat (27.07.2026 bis 25.08.2026). Version latest: 0.4.0 (veröffentlicht am 27.07.2026).

Vorbehalte: Die GitHub-API nutzt open_issues_count (41), was offene Pull Requests einschließen kann, weshalb es nicht als reine Issue-Zahl gelesen werden sollte. Das Feld watchers_count spiegelt die Sternezahl; die separate Abonnentenzahl ist subscribers_count (171). Die 62-Commits-Zahl wurde aus dem Link-Paginierungs-Header der Commits-API ermittelt (rel="last" auf Seite 62).

Wie man beiträgt

Der Prozess ist in CONTRIBUTING.md dokumentiert und offen (anders als bei google/skills):

Unterzeichne Googles CLA unter cla.developers.google.com, bevor du beiträgst (du oder dein Arbeitgeber behaltet das Urheberrecht; das CLA erteilt die Erlaubnis zur Nutzung und Weiterverbreitung). Hast du Googles CLA bereits für ein anderes Projekt unterzeichnet, musst du es wahrscheinlich nicht wiederholen.
Prüfe die Community-Richtlinien: Das Projekt folgt den Google Open Source Community Guidelines (opensource.google/conduct).
Beitragsfluss: „Alle Beiträge, einschließlich derer von Projektmitgliedern, erfordern eine Überprüfung. Wir nutzen dafür GitHub Pull Requests.”
Die Spec wird regeneriert: docs/spec.md gibt an, dass sie aus spec.mdx + spec-config.ts mit bun run spec:gen generiert wird („Do not edit directly”). Das CLI liegt in packages/cli (ein Monorepo mit turbo.json, tsconfig.base.json, und CI in .github/workflows/test.yml).

In der Praxis kommen jüngste Beiträge (sichtbar in den Releases) über PRs für das CLI (Linter-Bugs, Exports), zugeschrieben externen Contributorn (@rmyndharis, @Emp1500, @vikks, @SyedaQurratAI, @sbrsubuvga, @dalmaer, @arpitjain099).

Wie die Community es aufnahm

Die gesammelten Belege zeigen technisches Interesse und Begeisterung, zusammen mit einer konkreten Kritik am Umfang und der Notwendigkeit des Formats. (Der JSON-Endpunkt von Reddit lieferte in dieser Recherche eine Anti-Bot-Seite, weshalb keine Reddit-Reaktionen abgeleitet werden, die die Quellen nicht zeigen.)

Hacker News — Haupt-Thread 47887123 („Design.md: A format spec for describing a visual identity to coding agents”, 24. April 2026), 37 Punkte, 4 Kommentare:

aurareturn: „Very useful. Stealing it.” (sehr nützlich, klau ich mir).
gavmor — die substantiellste Frage: wie DESIGN.md „gut zusammenspielt” mit Figma Design Tokens oder tailwind.config.js; ob es die Quelle der Wahrheit sein wird oder nur darauf verweist, und worin es sich, jenseits deterministischer Validierung, von AGENTS.md unterscheidet; wirft die Frage des Umfangs in einer Zukunft diskreter Sub-Agenten auf.
brendanmc6 — eine gegenteilige Position: „ich bin die entgegengesetzte Richtung gegangen und habe entschieden, dass Design nicht in Artefakte oder langlebige Dokumente gehört. Ich bin in ein experimentelles Kaninchenloch namens specsmaxxing geraten… alles, was ich hier in DESIGN.md definiert sehe, ist bereits in meinen Theme-Configs oder Komponentendateien kodiert.”
necatiozmen: „DESIGN.md ist sehr nützlich für etwas schnell Betriebsbereites. Wir haben eine Seite gebaut, auf der man DESIGN.md-Dateien populärer Seiten erkunden kann: https://getdesign.md/”.

Hacker News — Thread 47718706 („Figma is dead. Long live DESIGN.md”, ein Artikel von typeui.sh/design-md, 10. April 2026), 7 Punkte, 12 Kommentare — die umfangreichste gefundene Kritik:

vrganj: „Warum automatisieren wir alle menschlichen kreativen Tätigkeiten und keine der lästigen Aufgaben? Wohin steuern wir, wenn wir eine Zukunft bauen, in der Menschen Toiletten putzen und Maschinen Kunst schaffen?”.
krapp (Antwort): „Das Endziel ist kapitalistischer Maximalismus. Künstler einzustellen ist teuer, also automatisiert man es. Weniger Hausmeister einstellen”.
levity: „der Zielmarkt für diese Art von Automatisierung sind Leute, die Design als lästige Aufgabe ansehen”.

Weitere HN-Threads (geringere Reichweite, zur Einordnung festgehalten):

47882713 — „Google: Stitch’s DESIGN.md format is now open-source” (der offizielle blog.google-Post), 3 Punkte, 0 Kommentare.
47852568 — „Google Launches Design.md” (Stitch-Docs), 2 Punkte, 0 Kommentare.
47719485 — „Show HN: Figma for Coding Agents” (getdesign.md), 11 Punkte, 6 Kommentare.
48924796 — „State of DESIGN.md 2026 – Survey results”, 3 Punkte.

Insgesamt spiegelt die Aufnahme eine Ressource mit echter Zugkraft wider (27.514 Sterne in vier Monaten und eine abgeleitete Community-Sammlung mit 110.550 Sternen), mit qualitativ hochwertiger technischer Diskussion über ihre Position gegenüber AGENTS.md und bestehenden Themes, sowie einem ideologischen/berufsbezogenen Einwand gegen die Automatisierung von Design.

design.md im Vergleich zu anderen Ansätzen

Projekt	Verifizierbare Überschneidung	Verifizierbarer Unterschied
`VoltAgent/awesome-design-md`	Eine Sammlung von `DESIGN.md`-Dateien, damit Coding-Agenten eine passende UI erzeugen.	Es ist ein Katalog von Beispieldateien (110.550 Sterne), nicht die Spec oder der Linter; es konsumiert das Format von `google-labs-code/design.md`.
`getdesign.md`	Eine `DESIGN.md`-Katalog-/Generator-Seite (300+ Seiten), die „der offiziellen Google-DESIGN.md-Spec folgt”.	Es ist ein kommerzielles Generierungs-Tool, nicht das Repo der offiziellen Spec.
Figma Design Tokens / das W3C-Design-Tokens-Format (`designtokens.org`)	Ein typisiertes, interoperables Token-Format (`{path.to.token}`).	Das sind reine Token-Formate, die auf Design→Dev abzielen; `DESIGN.md` fügt Design-Rational-Fließtext hinzu und richtet sich an Coding-Agenten. `DESIGN.md` exportiert nach `tokens.json` (DTCG).
`tailwind.config.js` / Tailwind-Themes	Definition von Farb-/Typografie-/Abstand-Tokens für eine App.	Es ist die Konfiguration eines konkreten CSS-Frameworks, keine portable Spezifikation; `DESIGN.md` exportiert nach Tailwind v3/v4.
`AGENTS.md` / `CLAUDE.md`	Anweisungen, die von Coding-Agenten in einem Repo gelesen werden.	Das sind allgemeine Prozess-/Codestil-Anweisungen; `DESIGN.md` spezialisiert sich auf visuelle Identität mit Tokens + Fließtext und Validierung (Linter, WCAG). Der Unterschied im Umfang wurde ausdrücklich von Nutzer `gavmor` im Thread 47887123 aufgeworfen.

Anwendungsfälle

Teams, die „Vibe Coding” betreiben und eine kohärente Marke wollen. Gründer und Entwickler, die mit KI Landing-Pages und Apps bauen und deren wiederkehrendes Problem ist, „es premiumhafter, konsistenter und weniger generisch aussehen zu lassen” (die auf der Seite getdesign.md erklärte Motivation), können ihre visuelle Identität einmal in einer DESIGN.md beschreiben und jeden Agenten sie auf jeder neuen Seite respektieren lassen, statt die Marke bei jeder Generierung neu zu erfinden.
Designer, die wollen, dass ihr Rational mit den Tokens reist. Wer eine visuelle Identität in Stitch (oder auf Papier) definiert, kann sie zwischen Projekten exportieren/importieren; das Format bewahrt, warum jeder Wert gewählt wurde, nicht nur den Wert, sodass Agenten die Absicht reproduzieren statt einer numerischen Kopie.
Ein Frontend-Team, das ein Theme (Tailwind) pflegt und eine portable Quelle der Wahrheit will. Über export --format json-tailwind / css-tailwind / dtcg lässt sich die Tailwind-Konfiguration oder ein interoperables tokens.json (Figma, Style Dictionary) aus der DESIGN.md ableiten, und lint/diff als CI-Gate nutzen, um defekte Referenzen, Nicht-WCAG-AA-Kontrast oder Regressionen zwischen Versionen zu erkennen.
Werkzeugübergreifende Coding-Agenten. In Abläufen, in denen dasselbe Projekt von Claude Code, Gemini CLI, Stitch oder anderen Tools angefasst wird, fungiert die DESIGN.md als gemeinsame, dauerhafte visuelle Referenz über Agenten und Sitzungen hinweg; npx @google/design.md spec erlaubt, die Spec als Prompt-Kontext einzuspeisen.
Wer Barrierefreiheit und Struktur automatisch validieren will. Der Linter mit seinen elf Regeln (WCAG-AA-Kontrast, defekte Token-Referenzen, Abschnittsreihenfolge, Tippfehler bei Schlüsseln) gibt ein deterministisches Gate über Dateien, die sonst nur ein Mensch überprüfen würde.

Ressourcen

Repository: https://github.com/google-labs-code/design.md
Dokumentation / offizielle Spezifikation: https://stitch.withgoogle.com/docs/design-md/specification · Spec im Repo: docs/spec.md
Philosophie des Formats: PHILOSOPHY.md im Repo
CLI (npm): https://www.npmjs.com/package/@google/design.md (Bin design.md / designmd)
Offizielle Beispiele: examples/atmospheric-glass, examples/paws-and-paths, examples/totality-festival (jeweils mit DESIGN.md, tailwind.config.js, design_tokens.json)
Launch-Blogartikel: https://blog.google/innovation-and-ai/models-and-research/google-labs/stitch-design-md/ („Stitch’s DESIGN.md format is now open-source for designers”, Cassia Xu, 21. April 2026)
Community-Sammlung: https://github.com/VoltAgent/awesome-design-md (110.550 Sterne) · https://getdesign.md
Umfrage: https://getdesign.md/state-of-design-md („State of DESIGN.md 2026”)
Relevante HN-Threads: 47887123 (37 Pkt.), 47718706 (7 Pkt., 12 Komm.), 47719485 (11 Pkt.), 47882713, 48924796
Video: „Del diseño al código en minutos con Google Stitch ✨ | Carlos Alarcón – AI” (YouTube, ID i9OiB3FNYcw, Kanal @alarcon7a)
Referenzformat: https://www.designtokens.org/ (W3C Design Token Format)
Schwester-Repos der Organisation: google-labs-code/stitch-skills (8.187), google-labs-code/stitch-sdk (1.787), google-labs-code/jules-awesome-list (3.158)

Dieser Artikel kombiniert README.md, PHILOSOPHY.md, CONTRIBUTING.md, docs/spec.md und die Beispiele des Repositorys, die Releases (0.1.0–0.4.0), den offiziellen Google-Post (21. April 2026), die GitHub-API und die npm-API, abgerufen am 26. August 2026. Stern- und Download-Zahlen ändern sich mit der Zeit. Die Umfragebehauptungen von getdesign.md (64.000+ Antworten, 102.000+ Sterne, 1.000.000+ Downloads) stammen von der Seite selbst und sind nicht unabhängig verifiziert.