AI UI Review-Checkliste: Generierte Interfaces vor dem Release testen

Beginnen Sie nicht damit, wahllos herumzuklicken und Eindrücke zu sammeln. Definieren Sie zuerst, was dieses Review beweisen soll. 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 „Einstellungen-Seite prüfen“.
• Produktanforderungen: Listen Sie die genehmigten Aktionen, Berechtigungen, Daten, Validierungsregeln, Bestätigungen, das Abbruchverhalten und die Recovery-Pfade auf, die gelten.
• Design-Autorität: Geben Sie die exakte DESIGN.md, das Token-Set, die Theme-Datei, die Komponenten-Richtlinie, das Referenz-Kit oder das genehmigte Design an, welches die Schnittstelle definiert.
• 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 realistische kurze, typische, lange, leere, ungültige und eingeschränkte Beispiele vor, sofern relevant.
• Erforderliche States: Benennen Sie die Idle-, Loading-, Success-, Empty-, Error-, Disabled-, Focus-, Selected-, Open- und Permission-States, die die Aufgabe tatsächlich erreichen kann.
• Ausschlüsse: Dokumentieren Sie Arbeiten, die außerhalb dieses Releases liegen, damit deren Fehlen nicht als Defekt missverstanden wird.

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

Beginnen Sie beim User-Ergebnis und gehen Sie jeden erforderlichen Zweig durch. Ein bestandener Test beschreibt 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 Aktion und gibt dem Nutzer einen möglichen nächsten Schritt vor.
• Ein Erfolg führt zur erforderlichen Bestätigung oder zum geänderten State.
• Ein Abbruch lässt Daten und Navigation im erwarteten Zustand zurück.
• Berechtigungseinschränkungen verhindern die Aktion und erklären, was der Nutzer als Nächstes tun kann.
• Ladezustände, leere Zustä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.“ Das 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 jeder Unterschied 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 die 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 benutzerdefinierte Textabstände erhöhen und Clipping, Überlappungen, Inhaltsverlust oder blockierte Steuerelemente dokumentieren.
• Jeden festgelegten Farbmodus und 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 benutzergewä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.

Nutzen Sie diese Überprüfung, um Bedenken zu identifizieren und Belege zu sammeln, aber halten Sie die Behauptungen begrenzt. 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 Namen von Steuerelementen, 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, belegbasierten 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 Test-Szenario (Fixture) anwenden

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

4. 4

   Erwartetes Ergebnis vor der Prüfung festlegen

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

5. 5

   Beobachtung und Belege 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 mag einen Bildschirm korrigieren, bewahrt jedoch 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 Test-Szenario: 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

   Zustand davor dokumentieren

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

3. 3

   Die definierte Autorität ändern

   Nehmen Sie die Änderung dort vor, wo das Team die Entscheidung verortet. 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. Das Protokoll nennt das fehlgeschlagene Szenario 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 Auswirkung beschreiben, nicht die visuelle Auffälligkeit. Ein subtiler Berechtigungsfehler kann das Release blockieren. Eine auffällige Abweichung in den Abständen kann eine geringe Schwere haben, wenn sie die Aufgabe nicht beeinträchtigt und vom Design-Verantwortlichen akzeptiert wird.

Identity Forge kann für diesen Prozess definierte Inputs bereitstellen: semantische Light- und Dark-Color-Tokens, Typografie, Vorgaben zu Spacing und Layout, Motive, Nutzungsregeln, DESIGN.md sowie Delivery-Formate wie Tailwind, DTCG und shadcn-orientierte Artefakte. Diese Inputs reduzieren Unklarheiten bei der Prüfung, ob eine generierte UI einem gewählten System entspricht.

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

Falls für ein Projekt keine Design-Autorität festgelegt wurde, sollte diese definiert werden, bevor die Konformität bestätigt wird. Die entsprechenden Leitfäden zu Designsystemen für Coding-Agenten, DESIGN.md und semantischen Color-Tokens erläutern mögliche Eingaben. Die Review-Methode selbst bleibt unabhängig vom verwendeten Tool.

• 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, Abstände, 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 den Anforderungen, der Designsystem-Quelle, dem Delivery-Mapping, der Implementierung oder dem Fixture zugeordnet.
• Eine kontrollierte, autoritative Ä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 vervollständigen Sie das Protokoll, bevor Sie den Rest der Schnittstelle prüfen. Wenn das erwartete Verhalten oder die Design-Instanz nicht benannt werden kann, stoppen Sie an dieser Stelle und adressieren Sie diese Lücke. Mehr Screenshots lösen keine fehlende Entscheidung.

• 7-point checklist to review any AI-generated UI: Der 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, echte 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 Artikel unterscheidet zwischen mechanisch prüfbaren Problemen und qualitativem Design-Review und deckt Palette, Typografie, Layout, Abstände, 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 verschiedene CSS-farbrelevante Eigenschaften ändern kann.
• Identity Forge: Identity Forge bietet Design-Kits mit semantischen Tokens, Typografie, Layout-Regeln, DESIGN.md-Richtlinien und Delivery-Routes 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, sich über Light- und Dark-Themes hinweg auf stabile Rollen zu beziehen.
• 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 Einsatzbereitschaft 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 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 von der qualitativen Design-Prüfung und deckt Palette, Typografie, Layout, Abstände, 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 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-Routen 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, sich über Light- und Dark-Themes hinweg auf stabile Rollen zu beziehen.
• 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.