benjaminstelzer/scoville-ui-anti-ai-slop

Scoville UI Anti-AI-Slop

Verbessere die Schnittstelle des Produkts. Behandle Bedienbarkeit, Informationsdesign, Adaption, Barrierefreiheit und Klarheit als Ergebnisse; installiere keine zweite Designsprache, die als bewährte Praxis getarnt ist.

Wenn der Nutzer dieses Skill explizit ausschließt, höre auf, bevor du eine Referenz liest, ein Skill-gesteuertes Werkzeug verwendest, etwas änderst oder eine Skill-basierte Vollständigkeitsbehauptung aufstellst. Eine Projekt- oder Host-Anweisung mit höherer Autorität kann es dennoch verlangen; melde diesen exakten Konflikt. Der Ausschluss eines verwandten Skills schließt nur dieses aus und berechtigt nicht dazu, dessen Vertrag hier zu reproduzieren.

Zuerst die Zuständigkeit klären

Behandle die folgenden Belange in dieser Reihenfolge:

1. System-, Sicherheits- und rechtlich bindende Barrierefreiheitsanforderungen;
2. die explizite Nutzeranfrage, einschließlich einer informierten Akzeptanz einer gemeldeten Einschränkung gegenüber einem nicht bindenden Ziel;
3. Repository-Anweisungen;
4. kanonische Produktanforderungen, Designsystem-Komponenten, Wrapper, Themes, semantische Tokens und genehmigte Assets;
5. das zuständige Framework oder die Plattform für ungelöste Belange;
6. bewusste lokale Muster, die mit diesen Zuständigen übereinstimmen; und
7. die allgemeinen UI-Prinzipien dieses Skills für die verbleibende Lücke.

Erlaube keiner niedrigeren Quelle, eine höhere Instanz zu überschreiben. Lege einen wesentlichen Konflikt offen. Eine wiederholte lokale Konvention zählt nur, wenn sie bewusst, aktuell und für dieselbe Oberfläche angemessen ist.

Wenn kein Barrierefreiheitsziel genannt ist, verwende WCAG 2.2 Level AA für Web-UI und die aktuelle Anleitung der zuständigen Plattform für andere Bereiche. Verwende unterstützte Komponenten und APIs. Wenn der kanonische Eigentümer die Mindestanforderungen nicht erfüllen kann, melde die genaue Einschränkung, anstatt sie mit einer parallelen Designsprache zu verbergen.

Lies framework-alignment.md, bevor du eine Entscheidung über die Zuständigkeit triffst, wenn der Stack unbekannt ist, die Zuständigkeit unklar ist, mehrere UI-Ebenen interagieren, kein kanonischer visueller Eigentümer zu existieren scheint oder der unterstützte Anpassungspfad unsicher ist.

Die Familienzuständigkeit getrennt halten

Dieses Skill arbeitet allein. Code ist zuständig für Engineering-Umfang, Code-Eigentum, Integrität, Risiko und Nachweise. UI ist zuständig für Framework-Ausrichtung, Hierarchie, Layout, Interaktionsdarstellung, responsive Anpassung und gerenderte Belege. Scribe ist zuständig für Bedeutung, Terminologie, Lokalisierung und Treue nur, wenn sichtbare oder zugängliche Formulierungen variabel sind; feste, quellengetreue Zeichenketten aktivieren Scribe nicht.

UI ist zuständig für Textlayout, Lesbarkeit, Abstände, Skalierung und ob eine erforderliche Bezeichnung oder ein zugänglicher Name existiert und zugeordnet ist. Scribe, wenn zutreffend, ist zuständig für das, was gesagt wird. Übernimm keine Regeln verwandter Skills und wiederhole nicht deren Überprüfung.

Die Arbeit lenken

1. Untersuche die angeforderte Oberfläche, Repository-Anweisungen, Framework-Version, kanonische Eigentümer und die nächstgelegene vergleichbare Oberfläche nur nach Bedarf.
2. Identifiziere die primäre Aufgabe, Priorität, betroffene Zustände, Inhaltsvariationen, Eingaben und responsive Transformationen.
3. Verwende kanonische Komponenten, Tokens, Varianten, Layouts, Breakpoints und Interaktionen wieder. Füge ein Primitiv nur für eine nachgewiesene Lücke bei dessen Eigentümer hinzu.
4. Nimm die kleinste kohärente Änderung für das Ergebnis und die notwendigen Zustände vor.
5. Überprüfe nur gerenderte Bedingungen, die das Ergebnis widerlegen könnten. Trenne gerenderte Belege, Quellinspektion und unbestätigtes Verhalten im Bericht. Für eine nicht implementierte Richtung oder eine reine Quellprüfung sage explizit, dass die Richtung oder die Ergebnisse nicht gerendert sind und das gerenderte Verhalten weiterhin unbestätigt ist; lade keine Validierung nur, um diese Grenze zu melden.

Lies ui-quality.md, bevor du eine Qualitätsentscheidung über Aufgabenablauf, Hierarchie, Layout, Lesbarkeit, Zustände, Barrierefreiheitsstruktur oder responsives Verhalten triffst. Für eine reine Belegfrage lade allein die Validierung, es sei denn, die Schnittstelle selbst muss ebenfalls beurteilt werden.

Lies validation.md nach einer Schnittstellenänderung oder bevor du gerendertes Verhalten, responsives Verhalten, beobachtete Interaktion, visuelle Qualität oder Barrierefreiheit behauptest. Lade es nicht für eine reine Quellprüfung, die die Ergebnisse auf die untersuchte Struktur beschränkt und das gerenderte sowie interaktive Verhalten explizit unbestätigt lässt. Ein Build oder eine Quellprüfung kann kein gerendertes Verhalten nachweisen.

Die UI-Integritätsgrenze schützen

Verbessere niemals das Aussehen, indem du eine parallele visuelle Sprache erfindest, ein semantisches Token umgehst, eine barrierefreie Komponente neu baust, Fokus- oder Eingabeanpassungen entfernst, erforderliche Inhalte verbirgst, einen visuellen Hinweis als alleinigen Bedeutungsträger verwendest, eine Wiederherstellung für einen geänderten Zustand weglässt oder eine lokale Ausnahme durch eine globale Theme-Überschreibung anwendest.

Erzwinge keine bevorzugten Schriftarten, Paletten, Radien, Schatten, Kartenmuster, Breakpoints, Pixelwerte oder modische Verbote. Quantitative Regeln stammen aus dem Barrierefreiheitsstandard, der Plattform oder dem Designsystem – nicht aus diesem Skill.

Wenn du nur prüfen oder beraten sollst, gib priorisierte Ergebnisse zurück, die an beobachtete Belege gebunden sind, und nimm keine Bearbeitungen vor.