AI UI Review-Checkliste

Beginnen Sie nicht damit, sich durchzuklicken und Eindrücke zu sammeln. Definieren Sie zuerst, was dieses Review beweisen darf. Ohne diesen Vertrag neigen Reviewer dazu, Anforderungen zu erfinden, persönlichen Geschmack als Defekt zu behandeln oder einen attraktiven Screen zu akzeptieren, dessen Hauptaufgabe nie abgeschlossen wird.

• User-Aufgabe: Formulieren Sie das Ergebnis aus Nutzersicht, z. B. „Teammitglied einladen und Bestätigung sehen“ statt „Einstellungenseite prüfen“.
• Produktanforderungen: Listen Sie die genehmigten Aktionen, Berechtigungen, Daten, Validierungsregeln, Bestätigungen, das Abbruchverhalten und die anwendbaren Recovery-Pfade auf.
• Design-Autorität: Nennen Sie die exakte DESIGN.md, das Token-Set, die Theme-Datei, die Komponenten-Richtlinien, das Referenz-Kit oder das genehmigte Design, das die Benutzeroberfläche steuert.
• Delivery-Artefakte: Dokumentieren Sie, wie diese Entscheidungen in das Projekt einfließen, z. B. über CSS-Variablen, Tailwind-Theme-Werte, DTCG-Tokens, einen shadcn-Registry-Eintrag oder generierte Dateien.
• Plattformen und Viewports: Fügen Sie nur die Browser, Geräte, Container-Breiten und Farbmodi hinzu, die das Produkt unterstützt.
• Content-Fixtures: Bereiten Sie – sofern relevant – realistische kurze, typische, lange, leere, ungültige und eingeschränkte Beispiele vor.
• Erforderliche Zustände: Benennen Sie die Idle-, Lade-, Erfolgs-, Leer-, Fehler-, Deaktivierungs-, Fokus-, Auswahl-, Open- und Berechtigungszustände, die die Aufgabe tatsächlich erreichen kann.
• Ausschlüsse: Dokumentieren Sie Arbeiten, die nicht Teil dieses Releases sind, damit deren Fehlen nicht mit einem Defekt verwechselt wird.

Ein generiertes Interface kann eine Art von Review bestehen und eine andere nicht. Halten Sie die Nachweise getrennt, damit ein starkes visuelles Ergebnis keine fehlerhafte Aufgabe kaschieren kann und eine funktionierende Aufgabe keine barrierefreie oder fragile Implementierung entschuldigt.

Beginnen Sie beim User-Ergebnis und arbeiten Sie jeden erforderlichen Zweig ab. Ein bestandener Test beschreibt ein beobachtbares Verhalten, keinen subjektiven Eindruck.

• Die primäre Aktion ist an dem Punkt sichtbar oder auffindbar, an dem der Nutzer sie benötigt.
• Labels beschreiben die resultierende Aktion und nicht eine vage Absicht.
• Die Navigation bewahrt den Kontext des Nutzers dort, wo die Anforderung dies vorsieht.
• Die Validierung identifiziert das betroffene Feld oder die betroffene Aktion und gibt dem Nutzer einen möglichen nächsten Schritt vor.
• Ein Erfolg führt zur erforderlichen Bestätigung oder zum geänderten Zustand.
• Ein Abbruch lässt Daten und Navigation im erwarteten Zustand zurück.
• Berechtigungsbeschränkungen verhindern die Aktion und erklären, was der Nutzer als Nächstes tun kann.
• Ladezustände, Leerzustände, Fehler, Wiederholungsversuche und Recovery-Pfade funktionieren, sofern sie im Scope liegen.
• Tastaturinteraktionen können die Steuerelemente der Aufgabe erreichen und bedienen, sofern die Tastaturnutzung unterstützt wird.

Akzeptanzkriterien als Beobachtungen formulieren. Beispiel: „Das Absenden einer gültigen Einladung deaktiviert das doppelte Absenden, zeigt den Fortschritt an, gibt eine Erfolgsmeldung mit der eingeladenen Adresse zurück und fügt das ausstehende Mitglied der Liste hinzu.“ Dies ist überprüfbar. „Der Einladungsflow fühlt sich intuitiv an“ ist es nicht.

Sichtbare Entscheidungen auf die festgelegte Instanz (Authority) zurückführen. Semantische Farben, Typografie-Rollen, Abstände, Layout, Motive, Komponenten-Styling und Modus-Verhalten prüfen. Nicht erklärte Werte dokumentieren, aber nicht davon ausgehen, dass jede Abweichung falsch ist. Eine lokale Ausnahme kann beabsichtigt sein, veraltet sein oder im System fehlen.

• Semantische Rollen: Komponenten verwenden Rollen wie background, foreground, primary, border, ring, success, warning und destructive für ihre beabsichtigte Bedeutung.
• Typografie: Die Rollen Heading, body, label, data und mono verwenden die festgelegten Schriftfamilien, Gewichte, Größen, Zeilenhöhen und Groß-/Kleinschreibungsregeln.
• Abstände: Wiederkehrende Abstände folgen der dokumentierten Skala, sofern keine genehmigte Ausnahme vorliegt.
• Layout: Seitenbreite, Grid, Ausrichtung, Dichte und responsive Übergänge entsprechen den festgelegten Regeln.
• Komponenten: Buttons, Inputs, Cards, Tabellen, Navigation, Overlays und Feedback-Elemente verwenden die vorgesehenen Varianten und Zustände.
• Modi: Light- und Dark-Werte behalten die gleiche semantische Bedeutung bei, und modusspezifische Ausnahmen sind dokumentiert.
• Motive: Dekorative Elemente erscheinen nur dort, wo die Instanz dies zulässt, und beeinträchtigen weder die Bedeutung noch die Interaktion.
• Hardcodierte Werte: Einmalige Farben, Schriftdeklarationen, Radien, Schatten und Abstandswerte haben eine dokumentierte Begründung oder werden zur Korrektur weitergeleitet.

Platzhalterinhalte durch Fixtures ersetzen, die das reale Layout stressen. Dieselbe Aufgabe über alle erforderlichen Viewports und Zustände hinweg prüfen, anstatt separate Screenshots als isolierte Kompositionen zu bewerten.

• Realistische Namen, Daten, Preise, Status, Beschreibungen und Datendichten verwenden.
• Lange Labels und Texte in übersetzter Länge testen, ohne die beabsichtigte Bedeutung zu ändern.
• Schmale und breite Layouts bei den unterstützten Container- oder Viewport-Größen prüfen.
• Zeilenumbruch, Kürzung (Truncation), Overflow, sticky-Bereiche, Overlays und Scroll-Verhalten verifizieren.
• Zoom oder Benutzer-Textabstände erhöhen und Clipping, Überlappungen, Inhaltsverlust oder blockierte Steuerelemente dokumentieren.
• Jeden festgelegten Farbmodus sowie alle unterstützten Forced-Color-Einstellungen verwenden.
• Focus-, Hover-, Active-, Selected-, Disabled-, Open-, Loading-, Empty-, Error- und Success-Zustände prüfen, die im Rahmen der Aufgabe erreicht werden können.
• Die Aufgabe mit langsamen oder fehlerhaften Daten wiederholen, sofern das Produkt diese Bedingungen unterstützt.

Der Forced-Colors-Modus verdient eine eigene Beobachtung, sofern er unterstützt wird. Browser können definierte Farben durch eine vom Benutzer gewählte Palette ersetzen, sodass Bedeutungen, die nur in einer benutzerdefinierten Füllung, einem Rahmen oder einem Schatten existieren, verschwinden können. Dokumentieren Sie, was wahrnehmbar bleibt, anstatt davon auszugehen, dass das Standard-Theme das Ergebnis vorhersagt.

Diese Überprüfung nutzen, um Bedenken zu identifizieren und Belege zu sammeln, aber die Behauptungen begrenzt halten. Visuelle Inspektion, Token-Konformität, automatisierte Prüfungen und KI-Kritik können jeweils Probleme finden. Keine dieser Methoden allein zertifiziert die Barrierefreiheit.

• Tastaturreihenfolge, Fokus-Sichtbarkeit, Bedienung der Steuerelemente und Fokus-Verhalten bei Overlays dokumentieren.
• Prüfen, ob Steuerelementnamen, sichtbare Labels, Anweisungen, Fehler und Zustandsänderungen im Kontext verständlich sind.
• Verifizieren, dass Informationen nicht allein durch Farbe oder visuelle Position vermittelt werden.
• Reflow-, Zoom- und Benutzer-Textabstandsverhalten auf den erforderlichen Oberflächen beobachten.
• Relevante Inhalte und Steuerelemente in unterstützten High-Contrast- oder Forced-Color-Einstellungen testen.
• Semantisches Markup, Verhalten von assistiven Technologien, Kontrastmessungen und formale Konformitätsfragen an den entsprechenden, beleggestützten Review-Track senden.

Oberflächen aus dem zu prüfenden Produkt auswählen. Eine Landingpage benötigt eventuell Navigation, ein Formular und Feedback. Eine Anwendung benötigt möglicherweise zusätzlich Datenansichten, Detailansichten, Overlays und Berechtigungszustände. Oberflächen, die das Produkt nicht verwendet, weglassen.

1. 1

   Eine Benutzeraufgabe auswählen

   Ein Ergebnis und die exakte Startbedingung benennen. Die Aufgabe eng genug fassen, um sie wiederholbar zu machen.

2. 2

   Repräsentative Oberfläche und Zustand auswählen

   Wählen Sie die Navigation, das Formular, die Datenansicht, die Detailansicht, das Overlay oder den Feedback-Zustand aus, der die weitreichendsten Auswirkungen hat oder eine spezifische Systemregel aufzeigt.

3. 3

   Festes Fixture anwenden

   Dokumentieren Sie Viewport, Modus, Inhalt, Konto- oder Berechtigungsstatus sowie die Datenbedingung. Verwenden Sie dieses Fixture nach Änderungen erneut.

4. 4

   Erwartetes Ergebnis vor der Prüfung formulieren

   Zitieren Sie die Anforderung oder Designregel und beschreiben Sie das beobachtbare Ergebnis. Wenn keine verbindliche Vorgabe existiert, brechen Sie ab und melden Sie die Lücke.

5. 5

   Beobachtung und Beleg erfassen

   Dokumentieren Sie, was passiert ist, wo es passiert ist und fügen Sie den kleinstmöglichen Screenshot, die Aufnahme, die DOM-Beobachtung, die Konsolenausgabe oder das Testergebnis bei, das zur Reproduktion erforderlich ist.

6. 6

   Schweregrad, Verantwortlichen und Entscheidung zuweisen

   Wählen Sie zwischen „bestanden“, „überarbeiten“ oder „blockieren“. Leiten Sie die Ursache an die korrekte Ebene weiter, anstatt jedes Problem der generierten Implementierung zuzuweisen.

Review ID: UI-REVIEW-____
Build or revision: ____
Reviewer: ____
Date: ____

User task: ____
Start condition: ____
Required outcome: ____
Surface: ____
Required state: ____
Viewport or container: ____
Color mode: ____
Input and content fixture: ____
Permission or account fixture: ____

Requirement authority: ____
Design-system authority: ____
Delivery artifact: ____
Expected rule or behavior: ____
Observed result: ____
Evidence reference: ____

Evidence track:
  - task completeness: pass | fail | not tested
  - design-system conformance: pass | fail | not tested
  - resilience: pass | fail | not tested
  - accessibility: pass | concern | not tested

Finding route: requirement | design system | delivery mapping | implementation | fixture
Severity: low | medium | high | release blocking
Owner of next decision: ____
Known limitation: ____
Disposition: pass | revise | block
Retest required: yes | no
Retest result: ____

Ein sichtbarer Defekt liegt oft downstream von der Stelle, an der die Änderung erfolgen muss. Das Beheben der nächstgelegenen CSS-Regel führt zwar dazu, dass ein Screen den Test besteht, bewahrt aber denselben Fehler für die nächste Generation.

• Lücke in den Produktanforderungen: Das beabsichtigte Verhalten, die Berechtigung, die Inhaltsregel, die Bestätigung, die Stornierung oder der Recovery-Pfad fehlt oder ist widersprüchlich. Beispiel: Es wurde nicht entschieden, ob das Entfernen eines Mitglieds eine Bestätigung erfordert. Nächster Verantwortliche: Produktentscheider.
• Lücke in der Designsystem-Quelle: Die Anforderung ist klar, aber dem maßgeblichen System fehlt eine Rolle oder Regel, um sie konsistent auszudrücken. Beispiel: Warnungen und destruktive Aktionen haben keine unterschiedliche dokumentierte Behandlung. Nächster Verantwortliche: Designsystem-Owner.
• Delivery- oder Mapping-Lücke: Die Quelle enthält die korrekte Entscheidung, aber der exportierte Token, das Framework-Mapping, der Registry-Eintrag, die Theme-Datei oder das installierte Artefakt verliert diese oder weist sie falsch zu. Beispiel: Die Quelle definiert eine Focus-Ring-Rolle, aber das ausgelieferte Theme ordnet die Komponente einer Border-Rolle zu. Nächster Verantwortliche: Artefakt- oder Integrations-Owner.
• Defekt in der generierten Implementierung: Anforderungen und ausgelieferte Regeln sind ausreichend, aber die generierte Benutzeroberfläche ignoriert, überschreibt oder implementiert sie falsch. Beispiel: Ein Button verwendet eine hartcodierte Farbe anstatt der ausgelieferten destruktiven Rolle. Nächster Verantwortliche: Implementierungs-Owner oder Operator des Coding-Agents.
• Ungültiges Review-Fixture: Die Erwartung nutzt nicht unterstützte Daten, eine ausgeschlossene Plattform, den falschen Kontozustand, einen veralteten Build oder eine Oberfläche außerhalb des Release-Vertrags. Beispiel: Ein Reviewer erwartet eine Admin-Aktion, während er ein schreibgeschütztes Konto testet. Nächster Verantwortliche: Reviewer oder Test-Owner.

Wenn mehrere Ebenen beigetragen haben, benennen Sie das früheste maßgebliche Versagen als primären Pfad und listen Sie downstream liegende Defekte separat auf. Dies verhindert, dass ein lokaler Patch eine fehlende Entscheidung verschleiert.

Die Inspektion zeigt, ob der aktuelle Snapshot mit seinem System verbunden ist. Ein kontrollierter Änderungstest prüft, ob diese Verbindung weiterhin funktioniert. Ändern Sie eine abgegrenzte Entscheidung in der definierten Autorität, leiten Sie diese über den normalen Delivery-Pfad weiter und prüfen Sie sowohl das beabsichtigte Update als auch nicht verwandte Werte.

1. 1

   Eine semantische Entscheidung wählen

   Verwenden Sie eine reversible, eng gefasste Rolle, wie z. B. den Warnhintergrund, den Focus-Ring, die Überschriftsschriftstärke oder eine kompakte Spacing-Stufe. Kombinieren Sie keine mehreren Bearbeitungen.

2. 2

   Vorher-Zustand dokumentieren

   Erfassen Sie den maßgeblichen Wert, den ausgelieferten Wert, die beabsichtigten Konsumenten, das repräsentative Fixture und einige benachbarte Werte, die unverändert bleiben müssen.

3. 3

   Die definierte Autorität ändern

   Nehmen Sie die Änderung dort vor, wo laut Team die Entscheidung hingehört. Das direkte Bearbeiten der gerenderten Komponente testet nicht die Propagation.

4. 4

   Normalen Delivery-Pfad ausführen

   Regenerieren, exportieren, installieren oder wenden Sie das Artefakt so an, wie das Projekt normalerweise Designentscheidungen erhält.

5. 5

   Die Kette verifizieren

   Bestätigen Sie, dass die Autorität, das Delivery-Artefakt und der beabsichtigte Interface-Konsument die neue Entscheidung enthalten.

6. 6

   Auf nicht verwandten Drift prüfen

   Vergleichen Sie die dokumentierten benachbarten Rollen und repräsentativen Oberflächen. Jede unerklärte Änderung führt zum Scheitern des Tests, selbst wenn sich das Ziel korrekt geändert hat.

7. 7

   Testwert wiederherstellen oder genehmigen

   Behandeln Sie die Änderung als Test, es sei denn, der zuständige Owner genehmigt sie als neue Designentscheidung. Dokumentieren Sie den Endzustand im Review.

• Bestanden: Jede erforderliche Aufgabe und jeder repräsentative Zustand erfüllt seine beobachtbaren Kriterien; Konformitätsunterschiede sind erklärt; erforderliche Resilienzprüfungen sind belegt; Barrierefreiheits-Einschränkungen sind explizit; es gibt keine ungelösten, release-blockierenden Befunde.
• Überarbeiten: Die Autorität ist klar und der Defekt ist abgegrenzt, reproduzierbar, zugewiesen und kann vor dem Release sicher erneut getestet werden. Der Record benennt das fehlerhafte Fixture und das erwartete Ergebnis.
• Block: Eine erforderliche Aufgabe schlägt fehl; eine destruktive oder irreversible Aktion ist mehrdeutig; Berechtigungen sind falsch; eine erforderliche Wiederherstellung ist nicht verfügbar; die maßgebliche Anforderung oder Design-Instanz ist ungeklärt; Belege für einen release-kritischen Zustand fehlen; oder eine kontrollierte Änderung offenbart eine fehlerhafte Propagation oder unrelated Drift.

Die Schwere (Severity) sollte die Konsequenz beschreiben, nicht die visuelle Auffälligkeit. Ein subtiler Berechtigungsfehler kann das Release blockieren. Eine auffällige Abweichung im Spacing kann eine geringe Schwere haben, wenn sie die Aufgabe nicht beeinträchtigt und vom Design-Verantwortlichen akzeptiert wird.

Identity Forge kann deklarative Inputs für diesen Prozess liefern: semantische Light- und Dark-Color-Tokens, Typografie, Spacing- und Layout-Richtlinien, Motive, Nutzungsregeln, DESIGN.md sowie Delivery-Formate wie Tailwind, DTCG und shadcn-orientierte Artefakte. Diese Inputs reduzieren Mehrdeutigkeiten bei der Frage, ob eine generierte UI einem gewählten System folgt.

Sie liefern keine Produktanforderungen, kein fertiges Komponentenverhalten, kein abgeschlossenes UI-Audit und keinen Nachweis darüber, dass eine Schnittstelle barrierefrei oder produktionsbereit ist. Sie entscheiden auch nicht, ob eine Abweichung eine genehmigte Ausnahme darstellt. Diese Entscheidung obliegt den Verantwortlichen für das Produkt, das Designsystem, die Implementierung und das Release.

Wenn ein Projekt keine deklarative Design-Instanz hat, sollte diese etabliert werden, bevor die Konformität beansprucht wird. Die zugehörigen Guides zu Designsystemen für Coding-Agenten, DESIGN.md und semantischen Color-Tokens erläutern mögliche Inputs. Die Review-Methode selbst bleibt werkzeugunabhängig.

• Die geprüfte Benutzeraufgabe, die Startbedingung und das erforderliche Ergebnis sind schriftlich festgehalten.
• Anforderungen und Designsystem-Instanzen sind benannt und versioniert oder anderweitig identifizierbar.
• Delivery-Artefakte und unterstützte Plattformen sind dokumentiert.
• Repräsentative Inhalte, Berechtigungen, Modi, Viewports und erforderliche Zustände sind festgelegt.
• Primäre Pfade sowie Abbruch-, Bestätigungs-, Fehler- und Wiederherstellungspfade funktionieren, wo erforderlich.
• Semantische Farben, Typografie, Spacing, Layout, Komponenten-Styling, Motive und Modi lassen sich auf die deklarative Instanz oder eine genehmigte Ausnahme zurückführen.
• Für lange Inhalte, schmale Layouts, Zoom oder Textabstände, Tastaturbedienung und relevante Nicht-Standard-Zustände liegen Belege vor.
• Barrierefreiheitsbedenken und ungeprüfte Bereiche sind explizit benannt; kein visueller Review oder KI-Review wird als Zertifizierung dargestellt.
• Jeder Befund wird an Anforderungen, die Designsystem-Quelle, das Delivery-Mapping, die Implementierung oder die Fixture weitergeleitet.
• Eine kontrollierte, maßgebliche Änderung erreicht das beabsichtigte Artefakt und den Konsumenten ohne unrelated Drift.
• Jedes ungeklärte Problem hat eine Schwere, einen Verantwortlichen für die nächste Entscheidung und eine Bedingung für den erneuten Test.
• Das Release-Protokoll endet mit „bestanden“, „überarbeiten“ oder „blockieren“ statt mit einem vagen Genehmigungskommentar.

Wählen Sie für den nächsten Review eine release-kritische Aufgabe aus und schließen Sie das Protokoll ab, bevor Sie den Rest der Schnittstelle prüfen. Wenn das erwartete Verhalten oder die Design-Instanz nicht benannt werden kann, stoppen Sie dort und adressieren Sie diese Lücke. Mehr Screenshots lösen keine fehlende Entscheidung.

• 7-point checklist to review any AI-generated UI: Der archivierte Artikel erklärt, dass polierte, KI-generierte Screens eine schwache Logik und fehlende Produktentscheidungen kaschieren können; daher sollte das visuelle Finish nicht mit Produktionsreife gleichgesetzt werden.
• AI Generated UI Quality Checklist: Die Checkliste empfiehlt, Hierarchie, Systemkonsistenz, reale Inhalte, responsives Verhalten, mobile Layouts und Nicht-Standard-Zustände zu prüfen, bevor eine generierte UI veröffentlicht wird.
• AI design review assistant for modern designers: Figma präsentiert den Design-Review als kontextuellen Feedback- und Iterations-Workflow, einschließlich der Prüfung ausgewählter Frames, Komponenten und Flows.
• A pre-ship design review checklist for AI-generated UI: Der archivierte Artikel trennt mechanisch prüfbare Probleme vom qualitativen Design-Review und deckt Palette, Typografie, Layout, Spacing, Zustände, Fokus und Motion ab.
• forced-colors CSS media feature: MDN dokumentiert, dass der forced-colors-Modus es dem Browser ermöglicht, eine vom Benutzer gewählte Farbpalette aufzuzwingen, was mehrere CSS-farbrelevante Eigenschaften ändern kann.
• Identity Forge: Identity Forge bietet Design-Kits mit semantischen Tokens, Typografie, Layout-Regeln, DESIGN.md-Richtlinien und Delivery-Routen für Coding-Agent-Workflows.
• So erstellen Sie eine DESIGN.md (und was sie ist): Eine DESIGN.md kann die Design-Intention, Farb- und Typographiesysteme, Layout- und Abstandsregeln, die Behandlung von Komponenten, Motive sowie explizite Nutzungsbeschränkungen für einen Coding-Agent dokumentieren.
• Semantische Color-Tokens erklärt: Semantische Color-Tokens benennen Farben nach ihren Rollen in der Benutzeroberfläche und ermöglichen es Komponenten, auf stabile Rollen über Light- und Dark-Themes hinweg zu verweisen.
• Shadcn Designsystem-Generatoren: Benötigen Sie ein Theme, ein System oder einen Agent-Handoff?: Der Artikel unterscheidet zwischen einem visuellen Theme und einem umfassenderen Designsystem und empfiehlt die Prüfung von Token-Bedeutungen, Komponenten-Mappings, Typografie, Layout-Richtlinien, Installationswegen und bekannten Lücken.

• 7-point checklist to review any AI-generated UI: Der vorliegende Artikel erläutert, dass polierte, KI-generierte Screens eine schwache Logik und fehlende Produktentscheidungen kaschieren können; daher sollte das visuelle Finish nicht mit der finalen Einsatzbereitschaft gleichgesetzt werden.
• AI Generated UI Quality Checklist: Die Checkliste empfiehlt, vor dem Release generierter UIs die Hierarchie, die Systemkonsistenz, reale Inhalte, das responsive Verhalten, mobile Layouts sowie Nicht-Standard-Zustände zu prüfen.
• AI design review assistant for modern designers: Figma präsentiert das Design-Review als einen Workflow für kontextuelles Feedback und Iterationen, einschließlich der Überprüfung ausgewählter Frames, Komponenten und Flows.
• A pre-ship design review checklist for AI-generated UI: Der vorliegende Artikel trennt mechanisch prüfbare Probleme vom qualitativen Design-Review und behandelt Palette, Typografie, Layout, Abstände, Zustände, Fokus und Motion.
• forced-colors CSS media feature: MDN dokumentiert, dass der Forced-Colors-Modus es dem Browser ermöglicht, eine vom Benutzer gewählte Farbpalette aufzuzwingen, was verschiedene CSS-farbrelevante Eigenschaften verändern kann.
• Identity Forge: Identity Forge stellt Design-Kits mit semantischen Tokens, Typografie, Layout-Regeln, DESIGN.md-Richtlinien und Delivery-Wegen für Coding-Agent-Workflows bereit.
• How to generate a DESIGN.md (and what it is): Eine DESIGN.md kann die Design-Intention, Farb- und Typographiesysteme, Layout- und Abstandsregeln, die Behandlung von Komponenten, Motive sowie explizite Nutzungsbeschränkungen für einen Coding-Agent dokumentieren.
• Semantic color tokens explained: Semantische Color-Tokens benennen Farben nach ihren Rollen in der Benutzeroberfläche und ermöglichen es Komponenten, auf stabile Rollen über Light- und Dark-Themes hinweg zu verweisen.
• Shadcn design system generators: do you need a theme, a system, or an agent handoff?: Der Artikel unterscheidet zwischen einem visuellen Theme und einem umfassenderen Designsystem und empfiehlt die Prüfung von Token-Bedeutungen, Komponenten-Mappings, Typografie, Layout-Richtlinien, Installationswegen und bekannten Lücken.