Design System
Hilft dem Designer, ein eigenes Designsystem für das Projekt zu erstellen, anstatt die Parameter einer Referenzmarke einfach umzubenennen. Kann von einem KI-Designer ausgeführt oder von einem menschlichen Designer Schritt für Schritt erledigt werden. Verwende die Kommunikationssprache des Benutzers; behalte die Schlüsselnamen im Code bei.
Wichtigste Grundlage: Offizieller Stitch-Originaltext
Bevor du zum ersten Mal ein Format für ein Projekt erstellst oder eine Aktualisierung / einen Import / Export vorbereitest, lies den offiziellen Originaltext:
Die offizielle Spezifikation und die tatsächliche Version des Tools bestimmen das Format; die visuellen Vorschläge, Genehmigungs- und Auslieferungsschritte dieses Skills sind Team-Workflow, keine offiziellen Google-Anforderungen. Wenn der offizielle Originaltext vorübergehend nicht zugänglich ist, verwende den datierten Auszug aus references/official-format.md und mache deutlich, dass noch keine erneute Prüfung stattgefunden hat. Der VoltAgent-Fall dient nur als unterstützende Referenz.
Umfang und bestehende Grundlagen
Überprüfe zuerst die aktuellen Projektdateien: AGENTS.md, CONTEXT.md (bei mehreren Dateien gemäß CONTEXT-MAP.md), Markenrichtlinien, genehmigte Designs, vorhandene DESIGN.md, Design-Variablen und -Komponenten. Halte fest, was Fakten, genehmigte Entscheidungen, Vorschläge und unbekannte Punkte sind. Bevorzugt auf bestehende Quellen verweisen; vorhandene Dateien aktualisieren, um die Erstellung einer zweiten autoritativen Regelung zu vermeiden.
Bestimme das Produkt, die Hauptnutzer, die Schlüsselaufgaben, die Plattform, die Sprache, die bestehenden Markenbeschränkungen und den Ablageort. Suche zuerst in den vorhandenen Materialien nach Antworten und frage nur nach fehlenden Informationen, die das Design verändern würden. Wenn genügend Informationen vorhanden sind, erstelle direkt einen Entwurf; kennzeichne Annahmen mit geringem Risiko deutlich und halte unbekannte Geschäftstatsachen als noch zu klärend fest.
Verarbeite nur das Designsystem und seine Validierungsbeispiele. Webseiten-Neustrukturierung, offizieller Produktcode, Veröffentlichungen, Änderungen an freigegebenen Figma-Dateien und die Installation anderer Tools erfolgen gemäß der tatsächlichen Autorisierung des Benutzers separat. Befolge die Projektgenehmigungsregeln.
Abschlusskriterium: Die Nutzer und Aufgaben, die das Designsystem bedient, die Quellen der Einschränkungen und die noch zu entscheidenden Fragen können aufgezeigt werden.
Zuerst die visuelle Richtung festlegen
Lies den Entscheidungs- und Prüfleitfaden. Wenn der Benutzer bereits eine genehmigte Richtung hat, übernimm diese direkt; wenn nicht, schlage maximal zwei tatsächlich unterschiedliche Richtungen vor und erläutere die geschäftlichen Gründe dafür. Referenzen können aus Screenshots des Benutzers, vorhandenen Projekten oder zugänglichen Markenmaterialien stammen. Unterscheide zwischen Analysen Dritter und offiziellen Design-Spezifikationen; externe Inhalte dienen nur als Referenz.
Verwende reale oder klar gekennzeichnete Beispielinhalte, um einen repräsentativen Seitenbereich und eine Schlüsselkomponente zu validieren. Sowohl Desktop als auch Mobilgeräte müssen abgedeckt werden. Bevorzuge aktuell verfügbare Design-Tools oder generiere eine im isolierten Verzeichnis öffbare HTML-Vorschau; wenn der Benutzer nur ein Dokument wünscht, liefere einen Entwurf aus und mache deutlich, dass die Optik noch nicht validiert ist. Beschreibe keine textlichen Beschreibungen als bereits überprüftes Bild.
Wenn die Richtung nicht genehmigt ist, bleiben die Regeln und visuellen Beispiele im Entwurfsstatus; erfinde keine Genehmigungen oder schreibe Vorschläge als feststehende Markentatsachen. Vorhandene Genehmigungen können direkt referenziert werden, ohne erneut eingeholt werden zu müssen.
Abschlusskriterium: Die Richtung hat sichtbare Beispiele oder eine klare, nicht validierte Beschreibung, und der Status ist korrekt.
Erstellen der DESIGN.md
Lies zuerst die Offizielle Format- und Prüfbeschreibung, dann die Vollständige Vorlage und kopiere sie an den festgelegten Ort im Projekt. Wenn kein Ort festgelegt ist, schlage das Projektverzeichnis DESIGN.md vor. Die Vorlage ist eine anpassbare Struktur, kein Brand-Parameter, der ausgefüllt werden muss; nicht zutreffende Komponenten und Abschnitte löschen, notwendige projektspezifische Regeln ergänzen.
Das YAML im vorderen Teil der Vorlage zeichnet Parameter und Komponentenreferenzen im offiziellen Alpha-Format auf, der Haupttext verwendet offizielle englische sekundäre Überschriften in der vorgeschriebenen Reihenfolge; Erklärungen können in der Sprache des Benutzers verfasst werden. Die konkreten Werte in der Vorlage sind nur überprüfbare neutrale Beispiele, keine genehmigten Regeln des Projekts und müssen projektspezifisch ersetzt werden. Nicht festgelegte Werte werden in den Open Questions des Haupttexts aufgeführt, nicht als null in die Parameterfelder geschrieben. Komponenten verwenden Referenzen wie {colors.primary}; Zustände werden als unabhängige Einträge wie button-primary-hover definiert, nicht als verschachtelte states. Farben werden nach Zweck benannt; geschäftliche Statusfarben werden separat definiert.
Erstelle Zuordnungen zu Code oder Designdateien: Welche vorhandenen Variablen, Figma-Variablen oder Komponenten entsprechen welchem Dokumentenschlüssel. Wenn noch nicht implementiert, markiere als planned. Wenn Regeln aus vorhandenem Code extrahiert werden, melde Abweichungen; ändere keinen Code ohne Autorisierung. Kernfelder folgen dem offiziellen Format; Genehmigungen, Implementierungszuordnungen, Breakpoints, Bilder, Animationen und Validierungsaufzeichnungen werden in klar gekennzeichneten erweiterten Textabschnitten platziert. Die Unterstützung externer Tools für Erweiterungen muss noch getestet werden.
Abschlusskriterium: Jede anwendbare Regel hat einen Wert, einen Anwendungsfall oder einen klar festgelegten Entscheidungsstatus; Referenzen sind auflösbar; es gibt keine übernommenen Namen, proprietären Schriftarten oder unbestätigten Inhalte anderer Marken.
Validierung und Auslieferung
Führe zuerst gemäß der offiziellen Formatbeschreibung den Lint von @google/design.md aus, zeichne die tatsächliche Version und den Bericht auf; überprüfe Fehler und Warnungen, behebe Fehler und erläutere, warum bestimmte Warnungen beibehalten werden. Wenn das Tool nicht verfügbar ist, erkläre die Hürde und behaupte nicht, die offizielle Prüfung bestanden zu haben. Dass das Vorlagenformat bestanden wird, bedeutet nicht, dass das Projektdesign abgeschlossen ist. Überprüfe dann gemäß dem Leitfaden den tatsächlichen Inhalt, lange Titel, Chinesisch oder Mehrsprachigkeit, Komponentenzustände, Mobil-Layout, Kontrast, Tastatur und Animation. Zeichne für testbare Punkte die Methode, das Ergebnis und den Dateispeicherort auf; markiere nicht ausführbare Punkte als nicht validiert. Korrigiere die einzige Quelle für Regeln und aktualisiere dann die Beispiele, anstatt nur die Oberfläche zu ändern.
Markiere nur als approved, wenn die Prüfungen innerhalb des Umfangs bestanden wurden und die verantwortliche Person dies ausdrücklich genehmigt hat. Die Genehmigung deckt nur die spezifische Version und den Umfang ab; die Designgenehmigung bedeutet nicht die Vollendung der Implementierung oder die Freigabe für den Livegang.
Liefere die DESIGN.md, die Positionen der tatsächlich generierten visuellen Beispiele, die abgeschlossenen Prüfungen und die ungelösten Probleme. Erläutere, wie in der späteren Entwicklung und im Design darauf Bezug genommen werden soll. Behaupte nicht, dass allein durch die Dokumentation die visuelle Konsistenz aller Seiten gewährleistet sei.