spnngl/agent-skills

UI-Experte

Diese Skill entscheidet, was die Oberfläche ist, und beweist, dass sie für Menschen funktioniert. Code-Idiome (TypeScript, React, Next.js, Tests, Lint) stammen aus der ts-coding-Skill: Laden Sie diese immer, wenn Sie .ts oder .tsx berühren.

Arbeitsablauf

1. Orientieren. Lesen Sie die Quellen der Wahrheit der UI: package.json (react, next, tailwindcss, die Primitive-Bibliothek: react-aria-components, @radix-ui/*, @base-ui-components/react, oder shadcns components.json; das Icon-Set; @playwright/test, @axe-core/playwright), das Stylesheet mit @import "tailwindcss" und @theme, der Dark-Mode-Mechanismus, das gemeinsame Komponentenverzeichnis und zwei oder drei bestehende Bildschirme neben dem, den Sie ändern. Die bestehenden Entscheidungen des Projekts überschreiben die Standardeinstellungen dieser Skill; verwenden Sie seine Primitiven, Tokens, den Abstandsrhythmus und die Terminologie wieder. Erledigt, wenn: Sie das Styling-System, die Token-Datei, die Primitive-Bibliothek, das Icon-Set, den Theme-Umschalter, den Dev-Befehl und die URL, die die Arbeit rendern, und den Browser-Test-Runner (oder dass keiner existiert) benennen können.

2. Das Briefing erstellen. Schreiben Sie vor jedem Markup diesen Block in Ihre Antwort und bauen Sie darauf auf:

   Nutzer und Aufgabe: Wer dies verwendet und die eine Aufgabe, die es erfüllt
   Leit-Element:       Das einzelne Element, auf das das Auge zuerst fällt
   Primäre Aktion:     Die eine bejahende Aktion; destruktive Aktionen separat benannt
   Dichte:            spärlich | komfortabel | dicht, abgestimmt auf benachbarte Bildschirme
   Stimmung:          Ein Adjektiv, das das Ergebnis verdienen muss ("präzise", "ruhig", "warm")
   Zustände:          Leer, Laden, Fehler, Teilweise, Überlauf, Keine Berechtigung: die zutreffenden
   

   Layout, Komposition und visuelle Handwerkskunst: references/taste.md. Erledigt, wenn: jedes Feld eine konkrete Antwort für diesen Bildschirm enthält, spezifisch genug, dass ein Prüfer einen Build ablehnen könnte, der dies nicht erfüllt.

3. Tokens auflösen. Ordnen Sie jede Farbe, Größe, Abstand, Radius, Schatten und Dauer einem semantischen Token aus Schritt 1 zu. Fügen Sie einen fehlenden Token an der Quelle mit hellen und dunklen Werten hinzu, gemäß references/tokens.md. Erledigt, wenn: der Diff keine rohe Farbe, keinen beliebigen Wert (p-[13px], bg-[#1a1a1a]) und keinen Inline-Stil für eine thematisierbare Eigenschaft enthält, jeder neue Token einen hellen und einen dunklen Wert hat und node scripts/contrast.ts <theme.css> (Pfad relativ zum Verzeichnis dieser Skill) besteht.

4. Bauen. Bauen Sie aus den Primitiven des Projekts (React Aria Components, wenn es keine hat) zusammen, Mobile-First, gemäß Regeln und references/components.md. Semantik, Tastatur und WCAG-Detail: references/accessibility.md. Oberflächentexte: references/copy.md. Erledigt, wenn: jedes interaktive Element jeden zutreffenden Zustand abdeckt, jede Datenansicht jeden im Briefing genannten Zustand rendert und die unpräfixierten Styles das 320px-Layout sind.

5. Verifizieren. Führen Sie die Checks von ts-coding aus, dann die statischen und Browser-Gates in references/verification.md: Token-Drift, Emoji, Token-Kontrast, axe in Hell und Dunkel, Tastatur, Reflow bei 320px, Zielgröße, reduzierte Bewegung. Erledigt, wenn: jedes Gate mit Exit 0 beendet wird und Sie berichten, was jedes ausgegeben hat; ein Gate, das Sie nicht ausführen konnten, wird als "nicht verifiziert" mit Angabe des Grundes gemeldet.

6. Betrachten. Machen Sie Screenshots der Arbeit bei 1280 und 390 Breite, Hell und Dunkel, plus jeden Zustand aus dem Briefing; öffnen Sie jedes Bild mit dem Lesewerkzeug und klicken Sie jedes Steuerelement. Dann argumentieren Sie für eine Ablehnung mit references/review.md. Wenn ein Subagent-Tool verfügbar ist, übergeben Sie die Screenshots und diese Datei einem neuen Agenten: Ein Kritiker, der den Bildschirm nicht gebaut hat, sieht ihn klarer. Erledigt, wenn: Sie jeden Screenshot betrachtet haben, jedes Steuerelement eine sichtbare Änderung bewirkt hat und jeder Kritische oder Schwere Befund behoben oder dem Benutzer gemeldet wurde.

Kleine Änderungen (eine Abstands-, Farb- oder Textkorrektur innerhalb einer bestehenden Komponente): Führen Sie Schritt 1, 3 und die statischen Gates von Schritt 5 aus, machen Sie dann einen Screenshot des geänderten Elements in Hell und Dunkel und betrachten Sie beide.

Überprüfen bestehender UI: Führen Sie Schritt 1 aus, schreiben Sie das Briefing aus Schritt 2, wie Sie es ableiten, führen Sie die Schritte 5 und 6 dagegen aus und berichten Sie im Format von references/review.md. Ohne ein Rendering, sagen Sie dies und beschränken Sie die Befunde auf das, was die Quelle beweist.

Regeln

Nachweise

• Geben Sie ein Kontrastverhältnis, ein Bestehen oder eine Punktzahl nur an, wenn ein Befehl es gerade ausgegeben hat; sagen Sie andernfalls "nicht verifiziert". Ein Gate, das übersprungen wurde (kein Browser, kein Server), hat nichts gemessen.
• Gates beweisen Korrektheit, niemals Qualität: Beurteilen Sie Hierarchie und Handwerkskunst anhand von Screenshots.

Hierarchie

• Ein Element führt: Das Leit-Element des Briefings ist das größte, schwerste oder kontrastreichste Element, und seine Geschwister werden leiser. Auf Marketing- und Landingpages ist die Display-Schrift mindestens 2,5x so groß wie die Fließtext-Schrift; Produktbildschirme halten den Seitentitel eine oder zwei Stufen über dem Fließtext, wobei Gewicht und Position den Rest erledigen.
• Abstände wachsen nach außen: Lücken innerhalb einer Gruppe < Padding ihres Containers < Abstand zwischen Abschnitten.
• Ein leerer Zustand füllt seinen Bereich und nennt die erste Aktion. Eine Seite endet absichtlich: einer Zusammenfassung, einem Footer, einem nächsten Schritt.

Tokens und Farbe

• Token nach Absicht: Wählen Sie den Token, dessen Bedeutung mit der Aktion übereinstimmt. Eine destruktive Aktion trägt den destruktiven Token sowohl an ihrem Auslöser als auch in ihrer Bestätigung; primär markiert die eine wichtigste bejahende Aktion pro Ansicht.
• Jeder Status paart Farbe mit einem Icon oder Text. Ein Akzent; Neutrale tragen den Rest.
• Theming ist eine Bearbeitung an der Token-Quelle: Jeder Bildschirm liest dieselben semantischen Tokens.
• Hell und Dunkel folgen der Systempräferenz; eine System / Hell / Dunkel-Einstellung überschreibt dies und bleibt erhalten (references/tokens.md).

Zustände

• Interaktive Elemente: Standard, Hover, Fokus-sichtbar, Gedrückt, Deaktiviert, Ausstehend, Ungültig, Ausgewählt. Jeder, der zutrifft, ist sichtbar unterschiedlich, in Hell und Dunkel; Selektoren in references/components.md.
• Ausstehend hält das Steuerelement in voller Stärke mit einem Spinner oder Fortschrittslabel (isPending, aria-busy). Deaktiviert markiert eine Aktion, die der Benutzer jetzt nicht ausführen kann, wobei der Grund in der Nähe sichtbar ist.
• Feedback berichtet, was passiert ist: Ein Erfolgs-Toast erscheint, nachdem sich die Daten geändert haben, und die Ansicht zeigt die Änderung bereits.

Layout

• Mobil ist die Basis: Unpräfixierte Utilities sind das Telefon-Layout; sm:, md:, lg: schichten auf breiteren Bildschirmen darauf auf. Komponenten, die in verschiedenen Breiten wiederverwendet werden, reagieren auf ihren Container (@container, @md:).
• Ein Bereich, der horizontal scrollt, zeigt einen sichtbaren Hinweis: einen Kantenverlauf, eine Scrollleiste.

Leitplanken

• Icons stammen von lucide-react (oder dem Set des Projekts) als SVG mit currentColor. Keine Emojis in UI, Texten, Code und Commits.
• Oberflächen trennen sich durch eine vollständige Haarlinien-Grenze, einen Oberflächenschritt oder Abstand. Eine farbige Grenze nur auf einer Seite einer Karte, eines Alerts, Toasts oder Callouts ist verboten.
• Inhalte sind realistisch: plausible Namen, lange Zeichenketten, große Zahlen, null und ein Element. Platzhaltertexte und Debug-Steuerelemente werden niemals im Produkt gerendert.

Referenzen

Laden Sie diejenige, die zu dem Branch passt, auf dem Sie sich befinden:

• references/taste.md: Slop-Anzeichen, Komposition, Typografie, Farbe, Tiefe; jeder neue Bildschirm oder jedes Restyling.
• references/tokens.md: Tailwind v4 @theme, semantische Tokens, System-Theme und seine Überschreibungseinstellung, Hinzufügen oder Auditieren von Tokens.
• references/components.md: React Aria Components, Zustandsattribute, Formulare, Overlays, Datenansichten, Icons, Bewegung.
• references/accessibility.md: Semantik, Tastatur und Fokus, Kontrast, WCAG 2.2-Kriterien, erzwungene Farben, RTL.
• references/copy.md: Labels, Fehler, leere Zustände, Bestätigungen, Toasts, Anzeichen für generierte Texte.
• references/verification.md: Drift-, Emoji- und Kontrastscans, Rendern von Komponentenzuständen, Playwright- und axe-Gates, Screenshot-Matrix.
• references/review.md: Kritiklinsen, Heuristiken, Schweregrad, Befundformat.