bompus/hr-stock-ui-audit

Stock UI Audit (Überprüfung von Vorlagen-UI)

Generierte und Starter-Kit-Oberflächen teilen einen wiedererkennbaren Look: ein Indigo- oder Violett-Akzent, ein Lila-zu-Blau-Heldenverlauf, überall Inter, milchige Karten, Emoji in der Navigation. Keines davon ist an sich falsch. Das Problem ist eine Entscheidung, die mit der Vorlage kam und nicht aus dem Produkt. Diese Fähigkeit findet diese Entscheidungen mit einem statischen Scanner und sortiert sie dann durch Beurteilung. Der Scanner produziert Kandidaten; erst die Triage produziert Ergebnisse.

Diese Fähigkeit entfernt nicht ausgewählte Standardeinstellungen. Sie erfindet keine Marke. Wenn das Produkt noch keine visuelle Richtung hat, sag das und frage nach einer, anstatt einen Standard durch einen anderen zu ersetzen.

Vor dem Scan

1. Lies das Briefing, die Design-Tokens und die Theme- oder Komponentenbibliotheks-Konfiguration. Notiere jede Farbe, Schriftart und Komponente, die das Produkt angefordert hat. Diese bleiben, auch wenn der Scanner sie markiert.
2. Lege den Modus aus der Anfrage fest:
   • Prüfung (Review): Melde nur Ergebnisse. Ändere nichts.
   • Bereinigung (Cleanup): Behebe bestätigte Funde, und zwar nur innerhalb des Bereichs, den der Benutzer genannt hat (eine Seite, ein Komponentenordner, die gesamte App). Melde alles, was dir außerhalb auffällt, anstatt es zu beheben.
3. Wähle den Scan-Bereich: die Quellordner, die UI rendern, nicht das gesamte Repository.

Scanner ausführen

bun <Pfad zu diesem Skill-Verzeichnis>/scripts/scan.mjs [--json] [--fail-on high|medium|low] <Pfade>...

Node 22 oder höher funktioniert auch. Es durchläuft Verzeichnisse, überspringt Abhängigkeits-, Build- und Coverage-Ausgaben sowie minifizierte Dateien und liest .html .css .scss .js .ts .jsx .tsx .vue .svelte .astro. Es gibt die Anzahl der gescannten Dateien aus. Exit 0 bedeutet, dass nichts den kritischen Schweregrad erreicht hat (Standard: high), 1 bedeutet, dass etwas erreicht wurde, 2 bedeutet fehlerhafte Verwendung oder null gescannte Dateien. Eine 2 ist niemals ein sauberes Ergebnis. Übergib --fail-on medium, wenn violette Akzente, eine einzelne Standard-Schriftart oder Emoji-Symbole den Lauf fehlschlagen lassen sollen. Füge den Scanner nicht als CI-Gate hinzu, es sei denn, du wirst darum gebeten.

Regel	Schweregrad	Erfasst
purple-blue-gradient	high	Verläufe, deren Stopps alle kühle Farbtöne mit mindestens einem Violett sind, in CSS oder Tailwind from-/to--Klassen
violet-accent	medium	Jedes hex, rgb, hsl, oklch oder bare HSL-Token, dessen berechneter Farbton im Indigo- bis Violett-Bereich liegt, plus Tailwind indigo/violet/purple-Klassen
gradient-text	medium	background-clip: text und bg-clip-text
single-stock-font	medium	Eine einzelne Standardschrift (Inter, Roboto, Poppins und ähnliche) als einzige benannte Schriftart über zwei oder mehr Deklarationen im gescannten Satz
emoji-icon	medium	Emoji in Überschriften, Buttons, Links, Navigationselementen oder icon/label/title-Feldern
neon-glow	medium	Schatten ohne Versatz, mit breiter Unschärfe in einer gesättigten Farbe und Tailwind-farbigen Schatten
frosted-glass	low	backdrop-filter: blur() und backdrop-blur
library-default-token	low	Unberührte Standard-Primärfarben von Bootstrap, Material, MUI, Ant Design, Chakra, shadcn/ui und dem Vite-Starter
tracked-caps	low	Großbuchstaben mit großem Buchstabenabstand

Die Schriftregel wird über alle Dateien in einem Durchlauf geprüft, scanne daher den gesamten UI-Bereich zusammen; das Scannen einer Datei nach der anderen verbirgt sie.

Jeden Treffer triagieren

Öffne jede markierte Zeile und lies genug drumherum, um zu sehen, wofür das Element ist. Gib jedem Treffer genau ein Urteil:

• Nicht ausgewählter Standard (Unchosen default): Nichts im Briefing, in den Tokens oder im Verlauf fordert es an, und es wirkt wie eine Startvorlage. Dies ist ein Fund.
• Bewusste Entscheidung (Deliberate choice): Das Briefing, eine Token-Datei, ein Markenleitfaden oder eine Commit-Nachricht zeigen, dass jemand es ausgewählt hat. Behalte es und nenne den Beleg.
• Fehlalarm (False positive): Der Treffer tut nicht das, was die Regel annimmt, z. B. ein Violett-Ton in einem Syntax-Highlighting-Theme, ein Weichzeichner auf einem modalen Hintergrund über unruhigem Inhalt oder ein Emoji in benutzergenerierten Beispieldaten. Lass es und erkläre warum.
• Ungeklärt (Unresolved): Du kannst nicht sagen, ob jemand es ausgewählt hat. Es ist kein Fund und du änderst nichts. Berichte, was fehlt, und die Frage, die es klären würde.

Beheben, was echt ist

• Behebe die Ursache, nicht die Zeile. Fünf Violett-Hexes bedeuten normalerweise ein fehlendes Akzent-Token; definiere die Palette und Schriftart des Produkts einmal und weise die Komponenten darauf hin.
• Wähle Ersatz, der dem Inhalt dient: Kontrast, der hält, ein Akzent, der die eine Aktion markiert, die zählt, eine Schriftart, die zur Leselast passt.
• Verändere niemals einen Wert nur, um den Bereich des Scanners zu verlassen, z. B. einen Farbton um ein paar Grad verschieben oder ein Hex gegen ein äquivalentes oklch() austauschen. Wenn die Farbe falsch ist, ändere sie; wenn sie richtig ist, behalte sie und dokumentiere warum.
• Ändere niemals eine Markenfarbe, einen Statusfarbe (Erfolg, Warnung, Fehler) oder einen Fokusindikator, um den Scan zu bestehen. Diese tragen Bedeutung; dokumentiere sie als absichtlich.
• Ersetze Emoji-Symbole durch das vorhandene Symbolsatz des Projekts. Füge eine neue Symbol-Abhängigkeit nur hinzu, wenn der Benutzer zustimmt.

Was der Scanner nicht sehen kann

Überprüfe diese, indem du die gerenderte Seite liest, da kein Mustervergleich sie findet:

• jeder Abschnitt, der aus der gleichen zentrierten Überschrift, Untertitel und zwei Buttons besteht
• ein Drei-Karten-Feature-Raster mit einem Symbol, Titel und einer Textzeile in jeder Karte
• ein kleines Badge oder Pill über der Hauptüberschrift
• Karten, die durch einen dicken farbigen linken Rand markiert sind
• ein Statistik-Banner mit großen Zahlen ("10k+ Nutzer", "99.9% Verfügbarkeit")
• nummerierte "1, 2, 3"-Schrittabschnitte
• ein dunkles Theme, das ohne die vom Briefing angeforderte Lichtoption erzwungen wird
• der gleiche große Eckradius und weiche Schatten auf jeder Oberfläche
• Abstände und Schriftgrößen, die die Skalierung des Projekts ignorieren
• Text, der jedes Produkt beschreiben könnte

Überprüfen

1. Führe den Scanner erneut im gleichen Bereich aus und bestätige, dass jeder verbleibende Treffer ein dokumentiertes Urteil hat.
2. Betrachte die gerenderte UI in den relevanten Größen (eine schmale Telefonbreite und mindestens eine Desktop-Breite), in jedem Theme, das das Produkt ausliefert.
3. Ein sauberer Scan sagt nichts über Barrierefreiheit, Layout oder Gesamtqualität aus. Überprüfe Kontrast und Fokus-Zustände bei allem, was du geändert hast.

Wenn du die UI nicht rendern konntest, sage, dass die Überprüfung nur statisch war.

Bericht

Schreibe den Bericht in dieser Reihenfolge:

1. Gescannter Bereich, gescannte Dateien, Modus und Exit-Code des Scanners.
2. Behobene Funde (oder im Prüfmodus vorgeschlagene), jeweils mit Datei:Zeile, der Regel und was ersetzt wurde.
3. Als absichtlich beibehaltene Treffer, jeweils mit ihrem Beleg.
4. Ungeklärte Treffer, jeweils mit dem, was fehlt, und der Frage, die es klärt.
5. Fehlalarme, jeweils mit einer Zeile zur Begründung.
6. Probleme, die der Scanner nicht sehen kann, falls du welche gefunden hast.
7. Wie du überprüft hast: Ergebnis des erneuten Scans, betrachtete Größen und Themes oder "nur statisch".