Eisernes Gesetz
HOLE DIE AKTUELLEN RICHTLINIEN BEVOR DU IRGENDEINE DATEI ÜBERPRÜFST. Wende niemals gespeicherte oder angenommene Regeln an – hole immer die aktuellen von der Quell-URL ab. Falls WebFetch fehlschlägt, melde den Fehler und fahre NICHT mit erratenen Regeln fort.
Überprüfung der Webschnittstellenrichtlinien
Prüft UI-Code anhand der Vercel-Webschnittstellenrichtlinien. Gibt strukturierte
Datei:Zeile-Ergebnisse aus.
Wann dieser Skill verwendet werden soll
Lade diesen Skill, wenn der Benutzer folgende Anliegen äußert:
- "Überprüfe meine UI"
- "Prüfe die Barrierefreiheit"
- "Führe ein Design-Audit durch"
- "Überprüfe die UX"
- "Prüfe meine Seite/Komponente anhand der Richtlinien"
- "Führe vor einem PR eine Design-Compliance-Prüfung durch"
Funktionsweise
- Richtlinien abrufen – hole die neuesten Regeln von der Quell-URL mittels WebFetch
- Dateien lesen – lies die angegebenen Dateien (oder frage den Benutzer, welche Dateien/Muster überprüft werden sollen)
- Regeln anwenden – prüfe alle Dateien gegen jede Regel der abgerufenen Richtlinien
- Ergebnisse ausgeben – melde Verstöße im Format
Datei:Zeile: [verletzte Regel]
Richtlinienquelle
Rufe vor jeder Überprüfungssitzung die aktuellen Richtlinien ab:
https://raw.githubusercontent.com/vercel-labs/web-interface-guidelines/main/command.md
Verwende WebFetch, um die neuesten Regeln zu erhalten. Der abgerufene Inhalt enthält alle Regeln und Anweisungen zum Ausgabeformat. CACHE NICHT und MERKE DIR KEINE Regeln über Sitzungen hinweg – hole immer die aktuellen.
Verwendung
Wenn der Benutzer Dateien oder ein Pfadmuster angibt:
- Rufe die Richtlinien von der Quell-URL ab
- Lese die angegebenen Dateien
- Wende alle Regeln aus den abgerufenen Richtlinien an
- Gib die Ergebnisse im von den Richtlinien vorgegebenen Format aus
Wenn keine Dateien angegeben sind:
Frage den Benutzer: "Welche Dateien oder Verzeichnisse soll ich überprüfen? (z.B. src/app/features/dashboard/ oder *.component.html)"
Ausgabeformat
Befolge das Format, das in den abgerufenen Richtlinien genau angegeben ist. Standardstruktur:
Datei:Zeile — [Regelname]: [Beschreibung des Verstoßes]
Beispiel:
dashboard.component.html:34 — Leerzustand: Kein Leerzustand für den Datenlos-Zustand definiert
dashboard.component.html:67 — Fokusmanagement: Interaktives Element hat keinen sichtbaren Fokusindikator
order-list.component.ts:89 — Ladezustand: Asynchrone Operation hat kein Lade-Feedback
Fehlerbehandlung
Falls WebFetch die Richtlinien-URL nicht abrufen kann:
- Melde: "Konnte die Webschnittstellenrichtlinien nicht von der Quell-URL abrufen. Abruf fehlgeschlagen: [Fehler]"
- Fahre NICHT mit erratenen oder erinnerten Regeln fort
- Schlage vor: "Versuche es erneut oder prüfe den Netzwerkzugriff auf raw.githubusercontent.com"
Erfinde NIEMALS Regelverstöße, wenn der Abruf fehlschlägt.
Einordnung in den Überprüfungs-Stack
Dieser Skill ist die dritte Ebene der UI-Überprüfung – führe für eine vollständige Abdeckung alle drei aus:
| Ebene | Werkzeug | Erfasst … |
|---|---|---|
| Ebene 1 – Design-Tokens | /lint-design-system | Hartcodierte Farben, rohe Abstände, Inline-Typografie, Touch-Target-Verstöße |
| Ebene 2 – WCAG-Barrierefreiheit | accessibility-auditor-Agent | Kontrastverhältnisse, ARIA-Labels, Tastaturnavigation, semantisches HTML |
| Ebene 3 – Web-Interaktionsmuster | web-design-guidelines (dieser Skill) | Ladezustände, Leerzustände, Fehlerbehandlung, Interaktionsmuster, Fokusmanagement |
Verwandte Skills
frontend-design– FÜHRE DIESEN SKILL VORHER AUS, um die ästhetische Ausrichtung und den DFII-Score festzulegendesign-system– Durchsetzung der Token-Compliance (Angular + Flutter)angular-ui-patterns– Angular-spezifische Doktrin zu Lade-/Fehler-/Leerzuständenaccessibility-audit– WCAG 2.1 AA-Compliance-Prüfer