11. August 2026 · Von YasKad
VoltAgent/awesome-design-md

Awesome DESIGN.md: visuelle Referenzen, damit ein Agent nicht blind gestaltet

VoltAgent/awesome-design-md · 117.842★ · 13.203 forks

Alles Wissenswerte über VoltAgent/awesome-design-md: eine kuratierte Sammlung von DESIGN.md-Dokumenten, die aus öffentlichen Oberflächen extrahiert wurden, um die Generierung von Interfaces durch KI-Agenten zu leiten.


Was Awesome DESIGN.md ist

Awesome DESIGN.md sammelt Textdokumente, die visuelle Systeme beschreiben, die auf öffentlichen Websites beobachtet wurden. Sein Ziel ist operativ: eine dieser DESIGN.md-Dateien in die Wurzel eines Projekts kopieren und einen Coding-Agenten bitten, eine Seite zu bauen, die mit dieser visuellen Sprache übereinstimmt.

Das README stellt DESIGN.md als ein von Design-Agenten lesbares Markdown-Dokument vor: Während AGENTS.md erklärt, wie ein Projekt aufgebaut wird, erklärt DESIGN.md, wie es aussehen und sich anfühlen soll. Jeder Eintrag umfasst ein visuelles Thema, eine Palette samt Farbfunktionen, Typografieregeln, Komponentenstile, Kompositionsprinzipien, Elevation, Einschränkungen, adaptives Verhalten und einen Anweisungsleitfaden für den Agenten. Zusätzlich enthält er helle und dunkle HTML-Vorschauen.

Es ist keine Komponentenbibliothek, kein Figma-Exporteur und kein Generator, der eine URL in Echtzeit untersucht. Es ist eine Sammlung editierbarer Referenzen, veröffentlicht unter MIT und ohne Gewährleistung bereitgestellt; das README stellt klar, dass die extrahierten Werte aus sichtbarem CSS stammen und das Repository keine visuelle Identität der analysierten Websites für sich beansprucht.

Illustration einer leuchtenden DESIGN.md-Datei an der Wurzel eines Projektbaums, mit Datenströmen, die sie mit Karten und Navigationsleisten verbinden.

Der Ursprung: eine Sammlung rund um Google Stitch entstanden

Die GitHub-API verortet die Erstellung von VoltAgent/awesome-design-md auf den 31. März 2026. Die urhebende Organisation ist VoltAgent; die abgerufene Quelle identifiziert keine Einzelperson als Erstellerin des Repositorys, weshalb keine individuelle Urheberschaft zugeschrieben wird. Der von der API zurückgegebene Hauptbeitragende ist necatiozmen mit 58 Beiträgen; doanbactam, LeeDoYup und omeraplak erscheinen mit je einem Beitrag.

Die Idee entstand nicht als eigene Spezifikation von VoltAgent. Das README behauptet, DESIGN.md sei von Google Stitch eingeführt worden, und verlinkt dessen Dokumentation und Spezifikation. Die praktische Spannung, die das Projekt zu lösen versucht, ist, dass ein Agent funktionalen Code ohne eine konsistente Designreferenz erzeugen kann: gegenüber Figma-Exporten, JSON-Schemata oder zusätzlicher Konfiguration schlägt die Sammlung Markdown-Text vor, den ein Agent direkt lesen kann.

Es wurde kein Launch-Beitrag von VoltAgent gefunden, der die Entstehungsgeschichte erzählt. Die überprüfbare Chronologie zeigt jedoch ein sehr junges Projekt: Auf Hacker News gab es im April und Mai 2026 drei direkte Einreichungen, alle ohne Kommentare, und der auf der Repository-Seite sichtbare erste Commit wird als first commit vor etwa fünf Monaten beschrieben.

Darstellung des Google-Stitch-Logos, das Lichtfäden webt, die sich in ein strukturiertes Markdown-Dokument verwandeln.

Philosophie und Prinzipien

Der Ansatz stützt sich auf vier im README sichtbare Entscheidungen:

  • Expliziter Kontext statt vager Nachahmung: Die Dokumente drücken Tokens, Hierarchien und Einschränkungen aus, nicht nur einen Screenshot oder ein Stil-Etikett.
  • Portables Markdown statt proprietärer Formate: Eine Datei in der Wurzel kann den Code begleiten und von verschiedenen Agenten gelesen werden, ohne dass ein spezielles Werkzeug zur Interpretation nötig wäre.
  • Systemtiefe statt dekorativer Oberfläche: Jeder Eintrag versucht, Komponenten, Zustände, Abstände, Komposition und Reaktion auf Bildschirmgrößen zu beschreiben.
  • Öffentliche Referenz mit Grenzen: Der Inhalt wird „wie besehen” angeboten und als Extraktion öffentlich sichtbaren CSS präsentiert, nicht als Eigentum oder Autorisierung der gelisteten Marken.

Das Ergebnis ist eine Bibliothek von Design-Kontext, keine Garantie für Pixelgenauigkeit oder Markenkonformität: Diese Schlussfolgerungen hängen vom Agenten, vom Produkt und von der menschlichen Überprüfung ab.

Vier futuristische Monolithen, die die Prinzipien expliziter Kontext, Portabilität, Systemtiefe und Grenzen der öffentlichen Referenz darstellen.

Wie es funktioniert

Der dokumentierte Ablauf ist bewusst kurz:

  1. Eine Website aus der Sammlung wählen, organisiert in Kategorien wie KI-Plattformen, Entwicklertools, SaaS-Produkte, Design, Finanzen, Handel und Automobilbranche.
  2. Ihre DESIGN.md in die Wurzel des Projekts kopieren.
  3. Den Agenten bitten, sie zu verwenden, zum Beispiel: build me a page that looks like this.
  4. preview.html oder preview-dark.html konsultieren, um Palette, Typografie und Komponenten zu prüfen, bevor das Ergebnis akzeptiert wird.

Der Inhalt definiert konkrete Regeln: Farbnamen und -codes mit ihrer Funktion, Typografiefamilien und -skalen, Buttons, Karten, Felder, Navigation, Raster, Schatten, Verbote und adaptive Richtlinien. So verfügt ein Agent über eine visuelle Spezifikation neben der technischen Spezifikation von AGENTS.md.

Futuristisches Diagramm des Arbeitsablaufs: eine Website wählen, ihre DESIGN.md kopieren und mit einem KI-Agenten eine Interface-Vorschau erzeugen.

Offizieller und halboffizieller Status

Das Konzept und das Format DESIGN.md werden in der offiziellen Dokumentation von Google Stitch vorgestellt, auf die das README selbst verlinkt. Das belegt die Verbindung zu Stitch, nicht eine Zertifizierung dieser Sammlung: awesome-design-md gehört VoltAgent, nicht Google, und die abgerufenen Quellen zeigen nicht, dass Google es in einen offiziellen Marktplatz aufgenommen oder als offiziellen Katalog unterstützt hat.

Sein praktischer Status ist daher halboffiziell in Bezug auf das Format: Es nutzt und erweitert eine von Google Stitch dokumentierte Konvention, aber seine Markenanalysen und sein Kuratierungsprozess sind community-getragen. Die mehr als hunderttausend Sterne zeigen Verbreitung auf GitHub an, entsprechen aber keiner formalen Standardbezeichnung.

Holografische Bildschirme mit der offiziellen Dokumentation von Google Stitch, verbunden mit Knoten für Community-Übersetzungen und -Forks.

Das Ökosystem

Verwandte VoltAgent-Repositories

Die Abfrage der öffentlichen Repositories von VoltAgent zeigt eine direkte Familie rund um Agenten und Designreferenzen:

  • VoltAgent/official-design-md: eine Sammlung von DESIGN.md-Dateien, die von den Unternehmen selbst veröffentlicht werden; 459 Sterne und 40 Forks.
  • VoltAgent/awesome-claude-design: 68 Inspirationen visueller Systeme im DESIGN.md-Format; 3.314 Sterne und 365 Forks.
  • VoltAgent/design-md: ein öffentliches Repository ohne Beschreibung in der API; 18 Sterne.
  • VoltAgent/voltagent: ein TypeScript-Framework für Agenten-Engineering; 10.264 Sterne und 1.069 Forks.
  • VoltAgent/awesome-agent-skills: eine Sammlung von Skills für verschiedene Agentenumgebungen; 29.469 Sterne und 3.172 Forks.
  • VoltAgent/awesome-claude-code-subagents und VoltAgent/awesome-codex-subagents: Sammlungen spezialisierter Subagenten; 23.973 beziehungsweise 5.905 Sterne.

official-design-md ist die nächstliegende Ergänzung: Es trennt First-Party-Referenzen von den kuratierten Extraktionen von awesome-design-md.

Baum aus Repositories mit VoltAgent im Zentrum, das Daten zu verwandten Projekten wie awesome-claude-design und awesome-agent-skills ausstrahlt.

Forks, Übersetzungen und Community-Erweiterungen

Die Forks-API gibt insgesamt 12.140 Forks zurück. Die nach abgerufenen Sternen bedeutendsten sind direkte Forks mit nahezu identischen Beschreibungen, keine eigenständigen funktionalen Ports: BiscuitCoder/awesome-design-md (11 Sterne), GitNimay/awesome-design-md (4) und ShadowAmitendu/awesome-design-md (3).

Die Repository-Suche identifiziert jedoch Übersetzungen und Erweiterungen, die nicht mit direkten Forks verwechselt werden sollten:

  • kzhrknt/awesome-design-md-jp: eine japanische Sammlung, die angibt, das Format von Google Stitch für CJK-Typografie zu erweitern; 891 Sterne und 66 Forks.
  • HU-UH/awesome-design-md: eine auf Chinesisch beschriebene Sammlung mit 55 Designsystemen für Agenten; 361 Sterne und 91 Forks.
  • bergside/awesome-design-skills: eine Liste von 67 DESIGN.md- und SKILL.md-Dateien für Claude Design, Google Stitch, Codex, Cursor und andere Tools; 2.148 Sterne und 195 Forks.
  • Meliwat/awesome-ios-design-md: eine Sammlung für Apps mit frameworkneutralen Dokumenten und Varianten für SwiftUI, Jetpack Compose und Expo; 149 Sterne und 15 Forks.
  • aaldere1/awesome-design-systems: ein Paperclip-Skill, der sich explizit auf VoltAgent stützt; 8 Sterne und ein Fork.

Es gibt außerdem Tools, die einen anderen Teil des Zyklus abdecken: adityarajdigital/designmd, jpoindexter/design-md-extractor und yuvrajangadsingh/brandmd extrahieren Systeme aus einer URL; sie sind keine gleichwertigen Sammlungen, sondern Alternativen zur Erstellung eines Dokuments.

Holografisches Panel mit GitHub-Metriken, das mehr als hunderttausend Sterne und zwölftausend Forks zeigt.

Zahlen zum Repository

Messung: 3. August 2026, GitHub-API und -Seite.

MetrikWert
Sterne106.243
Forks12.140
Echte Abonnenten418
Commits61
Von der API angegebene offene Issues312
LizenzMIT
HauptspracheKeine Hauptsprache von der API angegeben
Erstellung31. März 2026
Letzter Code-Push31. Juli 2026
Letzte Metadaten-Aktualisierung3. August 2026
Veröffentlichungen und Tags0 Veröffentlichungen und 0 Tags

Die von der API zurückgegebenen Hauptbeitragenden sind necatiozmen (58), doanbactam (1), LeeDoYup (1) und omeraplak (1). Die GitHub-Seite zeigt 61 Commits. Die allgemeine API dupliziert die Sternezahl in watchers_count; deshalb wird hier subscribers_count als tatsächliche Abonnentenzahl angegeben. open_issues_count kann offene Pull Requests einschließen, sodass 312 nicht zwangsläufig ausschließlich 312 Issues entspricht.

Wie man beiträgt

Das README verlinkt CONTRIBUTING.md und dokumentiert zwei Wege: bestehende Dateien verbessern — etwa Farben, fehlende Tokens oder schwache Beschreibungen korrigieren — und Issues eröffnen, wenn etwas nicht korrekt erscheint. Vor dem Einreichen eines Pull Requests verlangt es, zuerst ein Issue zu eröffnen, um den Vorschlag zu diskutieren und Feedback vom Maintainer-Team zu erhalten.

Die abgerufene Aktivität bestätigt sowohl Katalog- als auch Infrastrukturbeiträge: Der Pull Request #127 von Luc0-0 schlug eine Automatisierung zur Validierung der Sammlungsintegrität vor; #163 von Nyvo2010 schlug Vorschauen und schnelles Kopieren vor. Beide sind in der API als geschlossen verzeichnet; der abgerufene Status erlaubt nicht den Schluss, dass sie gemergt wurden.

Holografische Fenster mit Pull Requests und Issues, verbunden mit einem Kern, der Beiträge zur Sammlung validiert.

Wie die Community reagierte

Die abgerufene externe Evidenz ist bescheiden und sollte mit Vorsicht gelesen werden:

  • Die Hacker-News-Einreichung 48177822, veröffentlicht von DeathArrow am 18. Mai 2026 und direkt mit dem Repository verlinkt, erhielt 4 Punkte und 0 Kommentare. Das ist ein Signal der Entdeckung, kein Beweis für Zufriedenheit oder Kritik.
  • Die Einreichung 47654756 von vanyle erhielt 3 Punkte und 0 Kommentare; die 47822069 von granto erhielt 2 Punkte und 0 Kommentare. Es gibt keine Meinungen, die diesen Threads zugeschrieben werden können.
  • Als Signal praktischen Interesses innerhalb von GitHub eröffnete JacobH555 das Issue #42, um die Extraktion mobiler Oberflächen zu erweitern; es sammelte 5 Kommentare, bevor es geschlossen wurde. mhakimarifin bat in #247 um eine ui.shadcn-Referenz, mit 4 Kommentaren. Das sind Abdeckungswünsche, keine Qualitätsbewertungen.
  • Der überprüfbare Einwand betrifft die Pflege: fuleinist eröffnete #377, zum Abfragezeitpunkt noch offen, mit einem Titel, der auf defekte externe Links zu getdesign.md hinweist, und 2 Kommentaren. Abysssea stellte ein weiteres, geschlossenes Issue, #388, zur DNS-Vergiftung von getdesign.md, mit 2 Kommentaren. Die Titel erlauben keinen Schluss auf Ursache oder technische Lösung; sie zeigen aber, dass externe Abhängigkeiten und Links für Nutzende ein reales Anliegen sind.

Es wurden weder Hacker-News-Threads mit Kommentaren noch umfangreiche externe Rezensionen gefunden, die einen Konsens belegen würden. Die hohe Sternezahl allein ersetzt diese qualitative Evidenz nicht.

Bildschirme mit Hacker-News-Threads und GitHub-Issues zu Anfragen nach neuen Interface-Referenzen.

Awesome DESIGN.md im Vergleich zu anderen Ansätzen

Vergleich zweier Panels: ein starres JSON-Schema gegenüber einer lesbaren, anpassbaren DESIGN.md-Datei.

AnsatzÜberprüfbare ÜbereinstimmungÜberprüfbarer Unterschied
VoltAgent/official-design-mdBeide sammeln DESIGN.md-Dokumente für Agenten.Letzteres gibt an, dass seine Dateien von den Unternehmen selbst veröffentlicht werden; Awesome DESIGN.md analysiert öffentliche Websites.
kwakseongjae/oh-my-designVerteilt DESIGN.md-Referenzen für Coding-Agenten.Bietet Installation per einzelnem Befehl und gibt mehr als 400 bewertete Referenzen an; Awesome DESIGN.md dokumentiert das manuelle Kopieren einer gewählten Datei.
Meliwat/awesome-ios-design-mdBeide sind Sammlungen von Designsystemen in diesem Format.Sein erklärter Fokus liegt auf Mobile und listet SwiftUI, Jetpack Compose und Expo.
jpoindexter/design-md-extractorErzeugt von Agenten nutzbaren visuellen Kontext.Es ist ein Extraktor mit CLI und lokaler GUI ausgehend von einer URL; Awesome DESIGN.md verteilt bereits aufbereitete Analysen.
yuvrajangadsingh/brandmdExtrahiert eine DESIGN.md-Spezifikation von einer Website.Gibt Validierung durch den offiziellen Linter @google/design.md an; die abgerufenen Quellen für Awesome DESIGN.md geben dieses Tool nicht an.

Anwendungsfälle und wem dieses Repository helfen kann

  • Entwicklerinnen und Entwickler, die mit einem Agenten bei einer leeren Seite beginnen, können eine Referenz aus der Sammlung wählen, sie neben den Code legen und dem Agenten Tokens, Typografie, Zustände und visuelle Regeln geben, bevor sie das Interface anfordern.
  • Produktteams, die kohärente Prototypen benötigen, können preview.html und preview-dark.html nutzen, um sich auf eine visuelle Richtung zu einigen, und danach eine erste Implementierung mit derselben Spezifikation erzeugen.
  • Designerinnen oder Maintainer, die Beobachtungen öffentlicher Oberflächen in wiederverwendbaren Kontext verwandeln möchten, können Token- und Beschreibungskorrekturen beisteuern oder über den dem Pull Request vorgelagerten Issue-Ablauf eine neue Referenz anfragen.
  • Teams, die First-Party-Referenzen, japanischsprachige Inhalte oder eine bestimmte mobile Plattform benötigen, können die Sammlung je nach dokumentiertem Umfang jedes Repositorys mit official-design-md, awesome-design-md-jp oder awesome-ios-design-md ergänzen.

Ressourcen


Hinweis: Dieser Artikel kombiniert das README und die Beitragsdatei des Repositorys, die Dokumentation von Google Stitch, die GitHub-API und -Seite, öffentliche Issues und Hacker-News-Ergebnisse, abgerufen am 3. August 2026. Zahlen ändern sich mit der Zeit.

Kommentare