Dhodraj/UI-Design

Was macht UI-Design?

Ein Agent, der nach einem Bildschirm gefragt wird, schreibt den Bildschirm. Dieser Skill schließt die Lücke auf beiden Seiten davon. Zuerst die Entscheidung, wofür die Oberfläche gedacht ist und wie sie aussehen soll. Dann die Überprüfung, ob das gebaute Ding die Aufgabe erfüllt.

Zwei Regeln bestimmen alles Folgende. Nenne das Kunden-Outcome vor der ersten Datei. Betreibe das laufende Produkt, bevor du sagst, es funktioniert.

Wähle zuerst die Tiefe

Die Änderung	Stufen
Text, eine Farbe, eine Eigenschaft	1, 7, dann das Ergebnis betrachten
Eine Komponente, ein Zustand	1, 4, 6, 7, 9
Ein Bildschirm, ein Formular, ein Ablauf	0 bis 10, kurz
Eine neue Oberfläche oder "mach das modern"	0 bis 10 vollständig, mit Stufe 3 genehmigt vor Stufe 7
"Prüfe dies"	Verwende ui-review. Beginne nicht mit Bearbeitungen
"Finde mir eine Komponente für…"	Verwende ui-find

Sage, welche Tiefe du gewählt hast, in einer Zeile, bevor du beginnst. Eine Stufe wird nur übersprungen, wenn die Änderung nicht erreichen kann, was diese Stufe schützt.

0. Vorab-Check: Lesen des Projekts vor jeder Frage

Lies in dieser Reihenfolge und stoppe bei der ersten, die die Frage klärt:

1. DESIGN.md im Projektstamm. Ein Designsystem, das bereits existiert, hat Vorrang vor jeder Standardeinstellung in diesem Skill und jedem eigenen Geschmack. Folge ihm. Wo die Arbeit etwas benötigt, das die Datei nicht abdeckt, füge das der Datei hinzu, anstatt es in einem Stylesheet zu erfinden.
2. PRODUCT.md, README.md, .claude/, ein bestehendes Briefing.
3. Der Stack, das Styling-System und die verwendete Komponentenbibliothek.
4. Der nächstgelegene bestehende Bildschirm und die Tests, die ihn abdecken.

Ein Bildschirm, der dem eigenen System des Produkts widerspricht, ist ein Befund, keine Lizenz, ein drittes System zu starten.

1. Das Designsystem

references/design-system.md enthält das Format und beide Wege hinein.

Das Projekt hat	Tue dies
Eine DESIGN.md	Lies sie, folge ihr und sage das in einer Zeile
Ein echtes Designsystem im Code: Tokens, eine Theme-Datei, eine Tailwind-Konfiguration	Kodifiziere es in DESIGN.md, indem du die Werte aus dem Code liest, niemals durch Raten
Ein Live-Produkt oder eine Marke ohne schriftliches System	Kodifiziere vom echten Ding: rendere es, lies die berechneten Werte aus, zeichne sie auf
Nichts	Schreibe eine in Stufe 3, basierend auf der vom Benutzer gewählten Richtung

Schreibe niemals eine DESIGN.md, die Werte angibt, die das Produkt nicht verwendet. Ein kodifiziertes System ist eine Aufzeichnung dessen, was da ist. Ein neues System ist ein Vorschlag und wird als solcher markiert, bis der Benutzer ihn auswählt.

Prüfe die Datei, bevor du darauf aufbaust:

pnpm dlx @google/design.md lint DESIGN.md

Es ist ein echtes veröffentlichtes Paket. Es erfasst defekte Token-Referenzen, fehlendes primary, nie definierte Typografie und jede Komponenten-Farbkombination unter dem Kontrast-Minimum von 4,5:1. Behebe, was es meldet, vor Stufe 7.

2. Das Kunden-Outcome

references/product-thinking.md enthält die Methode. Das Geschäftsergebnis, der Kunde und seine Aufgabe und die kleinste nützliche Version. Jeweils zwei Zeilen.

Schreibe das Outcome als etwas Beobachtbares:

Ein Disponent mit 40 offenen Fahrten kann sehen, welche Fahrt verspätet ist und sie neu zuweisen, ohne die Liste zu verlassen.

Dann Akzeptanzkriterien, die jeweils im Browser überprüfbar sind. "Sieht gut aus" ist kein Kriterium. "Bei 375px sind der Status jeder Fahrt und ihr Neuzuweisungs-Steuerelement ohne horizontales Scrollen erreichbar" hingegen schon.

Wo es keine Belege gibt, schreibe die Annahme und kennzeichne sie. Erfinde niemals eine Persona, ein Zitat oder eine Conversion-Zahl, die niemand geliefert hat.

3. Richtungen und die Wahl des Benutzers

references/directions.md enthält die Methode und das Vokabular.

Teile drei Richtungen aus, nicht eine. Ein einzelner Vorschlag ist die Standard-Ästhetik des Modells, verpackt in einer Begründung. Jede Richtung erhält einen Namen, den Anker-Farbton, die Typografie-Paarung, die Dichte und das eine einprägsame Merkmal, in vier Zeilen.

Dann halte inne und lege sie dem Benutzer mit dem interaktiven Fragenwerkzeug vor. Dies ist eine Genehmigungs-Pforte: Baue nicht auf einer Annahme daran vorbei. Wenn der Benutzer sagt "such du aus", wähle eine aus, sage welche und warum in einer Zeile und fahre fort.

Bei einem Ja schreibe oder aktualisiere DESIGN.md mit den echten Werten der gewählten Richtung und prüfe sie mit Lint.

4. Der Ablauf und seine Zustände

references/journey-and-states.md.

Liste die Zustände auf, die diese Oberfläche wirklich hat: leer, ein Element, viele, der dichteste echte Fall, Laden, teilweiser Fehler, Fehler, keine Berechtigung. Ein Bildschirm, der mit nur einem Fixture gebaut wurde, verbirgt alle anderen Zustände, und das ist der häufigste Grund, warum ein fertiger Bildschirm beim Kontakt mit einem Kunden versagt.

5. Finde Komponenten, bevor du sie schreibst

Führe ui-find oder sein Skript direkt aus:

node .claude/skills/ui-design/scripts/find-components.js <begriffe> --limit 15

Durchsuche zuerst die eigenen Komponenten des Projekts. Eine zweite Implementierung einer Komponente, die das Produkt bereits hat, ist ein Fehler. Schreibe eine Komponente nur dann von Grund auf neu, nachdem du die gelesenen Kandidaten benannt hast und warum jeder ungeeignet war.

6. Mock oder das echte Produkt

Frage, welchen Weg, in einer Zeile, es sei denn, der Benutzer hat es bereits gesagt. Beide Wege bauen echtes HTML und CSS; der Unterschied liegt darin, wo die Datei landet und womit sie verbunden ist.

Weg	Wann	Wohin es geht
Mock	Eine neue Oberfläche, ein Redesign, ein Stakeholder, der überzeugt werden muss, oder der Benutzer fragt danach	Eine eigenständige Seite unter mock/, mit den echten Design-Tokens und Beispieldaten, die auf den ersten Blick sagt, dass es sich um Beispieldaten handelt
Direkt	Eine Änderung innerhalb eines Live-Produkts oder der Benutzer sagt, baue es	Die eigenen Dateien des Produkts

Ein Mock wird genehmigt und dann in den Produktkomponenten neu gebaut. Sage das, bevor du ihn baust, damit niemand erwartet, dass die Mock-Datei ausgeliefert wird.

7. Bauen

Baue die Zustände aus Stufe 4, nicht nur den Happy Path. Verwende die eigenen Tokens und Komponenten des Produkts.

Lies references/gates.md und references/craft.md unmittelbar vor der ersten UI-Bearbeitung, jedes Mal, auch bei einer kleinen.

gates.md ist das Minimum: die Standardfehler, in die jedes Modell verfällt, und was stattdessen zu tun ist. craft.md ist die Schicht darüber. Tiefe als Schatten statt als Rand. Konzentrische Radien. Ausblenden unter 300ms. Eintritte, die einmal ausgelöst werden und nie bei einer wiederholten Interaktion. Tabellarische Ziffern. Zwei Teile eines Bildschirms verbunden, damit der Kunde sieht, dass sie eins sind.

Baue den wichtigsten Bildschirm oder den Helden allein und zuerst. Überprüfe ihn, bevor du den Rest baust, mit frischen Augen: Ein Subagent ohne Erinnerung an die Entscheidungen erfasst, was du nicht kannst. Baue dann den Rest.

8. Führe es aus und sieh es dir an

Keine Quellcode-Überprüfung. Starte die Anwendung, öffne sie in einem Browser und verwende sie vom echten Einstiegspunkt aus, wie der Kunde es tun würde.

references/playwright.md enthält die Mechanik und was zu tun ist, wenn die Anwendung hier nicht startet.

Betrachte die Screenshots. Das Lesen einer Dateiliste ist kein Betrachten.

9. Überprüfen und beheben

Führe ui-review gegen das aus, was du gebaut hast. Es misst das Live-Rendering, durchläuft den Ablauf, prüft das Ergebnis gegen die DESIGN.md und sortiert die Befunde nach Schweregrad.

Behebe in der Reihenfolge des Schweregrads. Eine Änderung, die du nicht gegen das Outcome in Stufe 2 rechtfertigen kannst, ist ein Umfang, den niemand verlangt hat. Sage, was du unverändert gelassen hast und warum.

Dann references/regression.md: identifiziere die Abläufe, die bereits vor der Code-Änderung funktionierten, und trenne Fehler, die deine Änderung verursacht hat, von Fehlern, die bereits vorhanden waren.

10. Bericht

• Das Kunden-Outcome und ob es erfüllt ist.
• Die gewählte Richtung und von wem.
• Was gebaut oder geändert wurde, nach Datei.
• Was verifiziert wurde, mit welchen Mitteln, bei welchen Breiten, in welchen Zuständen.
• Was nicht verifiziert wurde und warum.
• Behobene Befunde und offene Befunde mit Begründung.
• Annahmen, die immer noch Annahmen sind.

Ehrlichkeit, die über jeder Stufe oben steht

• Berichte niemals eine Messung, die du nicht durchgeführt hast, oder einen Bildschirm, den du nicht gerendert hast.
• Benenne jeden Ersatz. Ein Fixture für Live-Daten, eine statische Seite für die Anwendung, eine lokale Schriftart für die der Marke.
• Wenn die Anwendung nicht gestartet oder erreicht werden kann, sage das und markiere jede Aussage über einen Ablauf als unverifiziert. Beschreibe die Quelle nicht, als ob du sie hättest laufen sehen.
• Erfinde niemals eine Metrik, ein Erfahrungsbericht, eine Logowand oder eine Kundenzahl. Wo die echte Zahl fehlt, hinterlasse ein beschriftetes Feld und sage, dass es leer ist.
• Ein Formular, hinter dem nichts steht, sagt das auf den ersten Blick. Eine Seite, die "Gesendet" ausgibt, ohne zu senden, ist ein Fehler, kein Platzhalter.
• Das selbstständige Durchlaufen eines Ablaufs findet Reibung. Es misst nicht, was Kunden tun.

Was dieser Skill entlehnt und von wo

NOTICE zeichnet es auf. Komponentenquellen und ihre Lizenzen sind in sources.json; scripts/check-sources.js validiert diese Datei und tests/run.sh testet die Skripte.