Shadcn Design-System-Generatoren: Brauchst du ein Theme, ein System oder einen Agent-Handoff?

Entscheide zuerst, welches Artefakt du benötigst. Ein visuelles Theme ändert Werte wie Farben, Schriftarten, Radius und Schatten. Ein implementierungsbereites Design-System verknüpft diese Werte mit semantischen Rollen und Nutzungsregeln. Ein Coding-Agent-Handoff platziert die Regeln und Tokens dort, wo ein Agent sie lesen oder installieren kann. Diese Kategorien überschneiden sich. Sie beschreiben das gelieferte Artefakt, nicht dessen Qualität.

Die beobachteten Tools verwenden ähnliche Bezeichnungen für unterschiedliche Outputs. Das offizielle shadcn/ui bietet anpassbare Open-Code-Komponenten und eine gemeinsame komponierbare Schnittstelle. Shadcn Design generiert Light- und Dark-Theme-CSS aus einer Primärfarbe. Shadcn Studio fügt einen größeren Theme-Editor mit Kontrollen, Vorschauen, Presets und Installationswegen hinzu. Identity Forge paketiert semantische Tokens mit schriftlicher Design-Anleitung und Agent-Delivery-Artefakten.

Der Vergleich nutzt vier Evidenzstufen. "Dokumentiert" bedeutet, dass eine feste Quelle die Fähigkeit bestätigt. "Teilweise" bedeutet, dass die Quelle eine engere Fähigkeit mit angegebener Grenze bestätigt. "Undokumentiert" bedeutet, dass die verfügbaren Belege sie nicht bestätigen, was kein Beweis für deren Abwesenheit ist. "Nicht anwendbar" gilt für Felder, die nicht zum Artefakt passen.

• Semantische Rollen: undokumentiert. Die zitierten Seiten bestätigen anpassbare Komponenten und Open Code, aber keinen semantischen Token-Output-Vertrag.
• Light- und Dark-Output: undokumentiert. Die Homepage enthält Light- und Dark-Interface-Bilder, aber dies dokumentiert nicht den Inhalt eines generierten oder verteilten Themes.
• Typografie-Kontrollen: undokumentiert. Die zitierten Belege bestätigen keine Typografie-Kontrollen als Teil eines Output-Vertrags.
• Abstands- und Layout-Anleitung: undokumentiert. Die zitierten Belege bestätigen keine exportierten Abstands- oder Layout-Regeln.
• Komponenten-Anleitung: teilweise. Die Quellen dokumentieren anpassbare Open-Code-Komponenten und eine gemeinsame komponierbare Schnittstelle, aber keine exportierten Design-Nutzungsregeln.
• Vorschauen: teilweise. Die Homepage zeigt repräsentative Interface-Oberflächen, aber die Belege bestätigen keinen interaktiven Theme- oder Export-Vorschau-Workflow.
• Export- oder Delivery-Form: dokumentiert. Die Dokumentation beschreibt Open-Component-Code, der über ein Flat-File-Schema und CLI verteilt wird.
• Registry-Delivery: undokumentiert. Die zitierten Auszüge bestätigen diesen Lieferweg nicht.
• Agent-lesbare Dokumentation: teilweise. In der Einleitung heißt es, dass KI-Modelle den Open Code und die konsistente API lesen können, aber es wird kein separates Dokument für Design-Regeln bestätigt.

• Semantische Rollen: undokumentiert. Die Seite dokumentiert generierte CSS-Variablen, legt aber nicht genug vom Output offen, um ein bedeutungsorientiertes Rollenset zu verifizieren.
• Light- und Dark-Output: dokumentiert. Der Generator gibt an, dass er beide Modi aus einer Primärfarbe erstellt.
• Typografie-Kontrollen: dokumentiert. Die Seite bietet separate Auswahlmöglichkeiten für Body- und Heading-Fonts.
• Abstands- und Layout-Anleitung: undokumentiert. Die Seite legt keine schriftlichen Abstands- oder Layout-Regeln fest.
• Komponenten-Anleitung: undokumentiert. Gestylte Vorschau-Screens etablieren keine exportierten Komponenten-Nutzungsanweisungen.
• Vorschauen: dokumentiert. Der Generator bietet Live-Previews für Landingpages, Dashboards und Charts.
• Export- oder Delivery-Form: dokumentiert. Er kopiert Tailwind v4 CSS-Variablen für Farben, Schriftarten, Radius und Schatten.
• Registry-Delivery: undokumentiert. Die zitierte Seite bestätigt keine Registry-Installation für das generierte Theme.
• Agent-lesbare Dokumentation: undokumentiert. Die Belege bestätigen kein Design-Briefing oder ein anderes Regelwerk, das mit dem Theme geliefert wird.

• Semantische Rollen: teilweise. Der Generator dokumentiert benannte Kontrollen wie primary und destructive, aber die Belege bestätigen kein vollständiges Inventar semantischer Rollen.
• Light- und Dark-Output: dokumentiert. Der Generator dokumentiert die shadcn-Theme-Anpassung und den Export innerhalb seines Theme-Workflows.
• Typografie-Kontrollen: dokumentiert. Die Dokumentation enthält einen Typografie-Tab.
• Abstands- und Layout-Anleitung: undokumentiert. Die zitierten Seiten bestätigen keine exportierten Abstands- oder Layout-Regeln.
• Komponenten-Anleitung: undokumentiert. Echtzeit-Vorschauen zeigen visuelle Effekte, aber die Belege bestätigen keine schriftlichen Komponenten-Nutzungsregeln im Export.
• Vorschauen: dokumentiert. Der Generator bietet Echtzeit-Vorschauen für Komponenten, Blocks und Templates.
• Export- oder Delivery-Form: dokumentiert. Die Quellen beschreiben kopierten Output, manuelles Setup und einen Registry-Weg.
• Registry-Delivery: dokumentiert. Die Dokumentation identifiziert die Registry-Installation als Pro-Option und das manuelle Setup als weiteren Weg.
• Agent-lesbare Dokumentation: undokumentiert. KI-gestützte Theme-Generierung ist dokumentiert, aber das ist etwas anderes als das Exportieren von Regeln für einen anderen Coding-Agent.

• Semantische Rollen: dokumentiert. Identity Forge dokumentiert 28 bedeutungsorientierte Farbrollen in beiden Modi sowie CSS, Tailwind und DTCG-Exporte.
• Light- und Dark-Output: dokumentiert. Der semantische Token-Guide und die öffentlichen Kit-Belege beschreiben separate Light- und Dark-Werte.
• Typografie-Kontrollen: dokumentiert. Öffentliche Kit-Daten enthalten Typografie-Rollen, Familien, Gewichte und eine Scale-Beschriftung.
• Abstands- und Layout-Anleitung: dokumentiert. Der DESIGN.md-Guide besagt, dass seine generierten Briefings Abstands- und Layout-Regeln enthalten.
• Komponenten-Anleitung: dokumentiert. Der DESIGN.md-Guide beschreibt Komponenten-Behandlungen und explizite Nutzungsbeschränkungen im schriftlichen Briefing.
• Vorschauen: dokumentiert. Öffentliche Kit-Seiten zeigen Kits auf repräsentativen Interface-Oberflächen.
• Export- oder Delivery-Form: dokumentiert. Die Produktquellen beschreiben DESIGN.md plus CSS, Tailwind, shadcn und DTCG Token-Formate.
• Registry-Delivery: dokumentiert. First-Party-Guides dokumentieren die shadcn-Registry-Installation neben CLI- und MCP-Routen.
• Agent-lesbare Dokumentation: dokumentiert. DESIGN.md liefert schriftliche Anleitungen, die an die Kit-Tokens gebunden sind.

In dieser Map gibt es keinen universellen Gewinner. Ein fokussierter Generator ist die bessere Wahl, wenn ein bestehendes shadcn-Projekt nur neue visuelle Variablen und eine Vorschau benötigt. Umfassendere Regeln werden nützlich, wenn Entwickler oder Agents neue Interface-Entscheidungen treffen müssen, ohne ständig das beabsichtigte System erraten zu müssen.

Führe dieses Arbeitsblatt an einem tatsächlichen Export durch. Es handelt sich um eine vom Leser durchgeführte Inspektion, nicht um einen Benchmark der oben genannten Tools. Verwende für jeden Kandidaten denselben Beispielinhalt, damit Unterschiede von den Artefakten und nicht von unterschiedlichen Test-Screens stammen.

• Testinhalt: Seitenhintergrund, Standard- und gedämpfter Text, primäre und destruktive Aktionen, ein Input mit Rahmen, ein ausgewähltes Steuerelement und ein Tastaturfokus-Zustand.
• Inspektion: Notiere, ob die Namen den Zweck beschreiben (z. B. background, foreground, primary, destructive, border, ring) oder nur visuelle Werte. Paare jede geprüfte Light-Rolle mit ihrem Dark-Gegenstück.
• Fehlerbedingung: Eine Komponente benötigt einen rohen Farbton, weil keine passende Rolle existiert; eine Light-Rolle hat kein Dark-Gegenstück; oder destruktive und Fokus-Zustände leihen sich eine unpassende Rolle aus.

• Testinhalt: Primäre und sekundäre Buttons, deaktivierte und Fehler-Inputs, Cards, Popovers, Navigation, eine Tabelle mit ausgewählten und Hover-Zeilen sowie ein Chart mit mehreren Serien.
• Inspektion: Verfolge sichtbare Farben bis zu den exportierten Rollen. Prüfe Foreground- und Background-Paare, Rahmen, Fokus-Indikatoren, Overlays, ausgewählte Zustände und Chart-Serien-Rollen.
• Fehlerbedingung: Der Screen erfordert improvisierte Werte; eine Rolle dient widersprüchlichen Zwecken; oder ein Zustand ist in einem Modus nicht mehr unterscheidbar. Notiere dies als Lücke im Kandidaten-Export, nicht als Beweis für alles, was das Tool unterstützen kann.

• Testinhalt: Seitentitel, Sektionsüberschrift, Fließtext, Formularlabel, Hilfstext, Tabellenwerte und ein Code- oder Identifikatorfeld, falls relevant.
• Inspektion: Notiere, ob das Artefakt Familien, Gewichte, Größen, Zeilenhöhen und Tracking auf benannte Rollen abbildet oder nur Font-Family-Werte liefert.
• Fehlerbedingung: Implementierer müssen Gewichte oder Behandlungen erfinden; eine Rolle bezieht sich auf ein nicht verfügbares Gewicht; oder die exportierten Werte widersprechen den schriftlichen Anweisungen.

• Testinhalt: Schmaleres Formular, Card-Grid, dichte Tabelle, Page-Header und responsive Navigation.
• Inspektion: Suche nach Regeln für Inhaltsbreite, Gutters, Sektionsabstände, Komponentendichte, Grid-Verhalten und responsive Änderungen. Prüfe, ob diese Regeln nach dem Export oder der Installation verfügbar bleiben.
• Fehlerbedingung: Eine Vorschau impliziert ein Layout, das das Artefakt nie beschreibt; der Export lässt die schriftlichen Regeln weg; oder ein anderer Implementierer muss Dichte und Struktur allein aus Bildern ableiten.

Ein Coding-Agent kann nur die Anleitung nutzen, die seinen Arbeitskontext erreicht. Bevor du einen Export als Agent-Handoff bezeichnest, beantworte diese Fragen für das tatsächliche Artefakt und Projekt.

• Framework-Annahmen: Welchen shadcn, Tailwind, Framework- oder Komponentenbibliothek-Kontext erwartet es? Notiere Versionen, wenn die Quelle sie liefert.
• Installationsweg: Erhält das Projekt kopiertes CSS, Komponenten-Code, ein per CLI angewendetes Bundle, ein Registry-Item, ein via MCP geliefertes Artefakt oder eine Kombination?
• Token-zu-Komponente-Mapping: Kann der Implementierer die Rollen für Buttons, Inputs, Cards, Popovers, Navigation, Tabellen, Charts, destruktive Aktionen und Fokus-Zustände identifizieren?
• Typografie-Entscheidungen: Sind die erlaubten Familien, Rollen und verfügbaren Gewichte explizit?
• Abstands- und Layout-Regeln: Beschreibt der Handoff die Anordnung von Seite und Komponenten oder nur Theme-Werte?
• Nutzungsbeschränkungen: Wird erklärt, wann eine Behandlung angewendet werden sollte oder nicht?
• Bekannte Lücken: Welche Werte oder Regeln erfordern noch eine Entscheidung durch einen Designer, Entwickler oder Agent?

Ein DESIGN.md hilft nur, wenn der Workflow es dorthin bringt, wo der Ziel-Agent es liest. Ein Registry-Item kann Werte installieren, ohne notwendigerweise die schriftliche Begründung in denselben Kontext zu legen. Untersuche beide Wege, anstatt davon auszugez gehen, dass ein installiertes Artefakt den vollständigen Handoff enthält.

Das öffentliche Ambient Sage Kit ist ein begrenztes Beispiel für einen umfassenderen Handoff. Seine veröffentlichten Daten listen 28 semantische Farbtokens für Light- und Dark-Modi auf. Die Seite stellt außerdem ein DESIGN.md bereit und identifiziert Installationspfade, einschließlich der Identity Forge CLI und der shadcn-Registry. Dies sind beobachtbare Eigenschaften dieses Kits, kein Beweis dafür, dass seine visuellen Entscheidungen für jedes Produkt geeignet sind.

Die veröffentlichte Typografie weist Plus Jakarta Sans den Heading- und Body-Rollen mit den Gewichten 400, 500, 600 und 700 zu. JetBrains Mono hat die Mono-Rolle mit den Gewichten 400, 500 und 700. Die Scale-Beschriftung ist compact-product. Die Schriftprojektquellen bestätigen, dass die benannten Familien existieren, aber sie zeigen nicht, dass diese Paarung, dieser Gewichtssatz oder diese Skala für jede Implementierung vorzuziehen ist.

Die öffentlichen Belege identifizieren das Artefakt und seinen angegebenen Umfang. Die Übernahme erfordert dennoch eine Inspektion. Prüfe, ob der gewählte Export alle 28 Rollen in beiden Modi beibehält, ob das Projekt die aufgeführten Gewichte lädt und ob das DESIGN.md die Person oder den Agenten erreicht, der es befolgen soll. Verfolge dann die Rollen durch die Komponenten des Arbeitsblatts. Dieser Artikel hat keinen vergleichenden Benchmark durchgeführt.

• Wähle kopiertes CSS, wenn die Aufgabe ein visuelles Refresh ist und das Projekt bereits über Komponenten-, Typografie-, Abstands- und Layout-Regeln verfügt.
• Wähle einen Theme-Editor oder ein wiederverwendbares Preset, wenn shadcn-Projekte konsistente visuelle Variablen und Vorschauen benötigen, während umfassendere Produktrichtlinien an anderer Stelle existieren.
• Wähle ein implementierungsbereites Design-System, wenn Implementierer gemeinsame semantische Rollen plus explizite Typografie-, Abstands-, Layout- und Komponenten-Anleitungen benötigen.
• Wähle einen Agent-Handoff, wenn ein KI-Builder diese Entscheidungen während der Implementierung beibehalten muss. Verifiziere, wie sowohl Tokens als auch schriftliche Regeln in seinen Kontext gelangen.

Nimm einen Kandidaten-Export und führe ihn durch das Arbeitsblatt durch, bevor du ihn zum Projekt hinzufügst. Die ungelösten Entscheidungen werden zeigen, ob das aktuelle Artefakt ausreicht oder ob die Arbeit einen umfassenderen Handoff erfordert.

• The Foundation for your Design System - shadcn/ui: Zeigt anpassbare Open-Code-Komponenten und repräsentative Light- und Dark-Interface-Oberflächen.
• Introduction - shadcn/ui: Dokumentiert Open Code, Komposition, Flat-File-Schema, CLI-Distribution und eine von KI-Tools lesbare API.
• Shadcn Theme Generator | Live Preview, Copy Theme CSS: Dokumentiert die Generierung aus einer Primärfarbe, Light- und Dark-Themes, Schriftkontrollen, Radius-Presets, Live-Previews und Tailwind v4 CSS-Variable-Output.
• Design Stunning UIs Faster with Shadcn Theme Generator: Dokumentiert Presets, Echtzeit-Anpassung, Typografie-Kontrollen, benannte Farbkontrollen, Kontrastvalidierung, Vorschauen sowie Theme-Import oder -Export.
• Shadcn Theme Generator Documentation: Dokumentiert Theme-Kontrollen, das Kopieren des Outputs, manuelles Setup und die Pro-Registry-Installation.
• Identity Forge: Dokumentiert Kits mit Schriftarten, semantischen Tokens, Abständen, DESIGN.md-Anleitungen, Vorschauen und Agent-Delivery-Pfaden.
• Ambient Sage Design Kit: Liefert öffentliche Belege für die semantischen Tokens, Typografie-Rollen und -Gewichte, die Compact-Product-Scale-Beschriftung, DESIGN.md, Exporte und Installationsziele des Anwendungsbeispiels.
• Semantic color tokens explained: Dokumentiert die 28 Light- und Dark-semantischen Rollen von Identity Forge sowie CSS, Tailwind und DTCG Exportformen.
• How to generate a DESIGN.md (and what it is): Dokumentiert den Umfang von DESIGN.md inklusive Design-Intention, Token-Referenzen, Typografie, Abständen, Layout, Komponenten-Behandlungen, Motiven und Nutzungsbeschränkungen.
• Design systems for AI coding agents: Dokumentiert die Bereitstellung von Tokens und DESIGN.md über MCP, CLI und shadcn-Registry-Routen.
• Plus Jakarta Sans: Bietet die Projektquelle für die im Ambient Sage Beispiel genannte Plus Jakarta Sans Familie.
• JetBrains Mono: Bietet die Projektquelle für die im Ambient Sage Beispiel genannte JetBrains Mono Familie.