Impeccable: 62 deterministische Regeln gegen KI-Slop

Seiten, die ein Modell gebaut hat, haben ein unverwechselbares Gesicht. Man kennt es: Inter überall, ein Violett-nach-Blau-Verlauf im Hero, Karten in Karten, grauer Text auf farbigem Grund und über jeder Überschrift eine schwebende Kachel mit abgerundetem Quadrat als Icon. Paul Bakaus hat diesem Gesicht einen Namen gegeben und dann einen Linter dafür geschrieben.

Impeccable ist ein Design-Skill für Coding-Agenten. In dieser Woche kamen rund 6.700 Sterne dazu, insgesamt steht es bei etwa 91.500. Der Werbesatz — „das Designvokabular für deinen Coding-Agenten“ — unterschlägt das eigentlich Ungewöhnliche: 62 seiner Prüfungen laufen als deterministische Regeln, ganz ohne Modell.

Was es konkret ist

Ein Skill, 24 Kommandos und ein Detektor. Angefangen hat es als Erweiterung von Anthropics frontend-design-Skill und ist zu etwas mit eigenen Meinungen gewachsen.

Die Installation ist ein einziger Befehl im Projektstamm:

npx impeccable install
/impeccable init

Der zweite Schritt ist der, den die Leute überspringen. init interviewt dich zum Produkt — Zielgruppe, Zweck, Randbedingungen, Ton — und schreibt die Antworten in PRODUCT.md. Ein separates document-Kommando erzeugt DESIGN.md aus dem vorhandenen Code. Die Trennung ist wichtig: Produktfakten und visuelles System sind zwei verschiedene Artefakte, die sich in unterschiedlichem Takt ändern, und sie in eine Datei zu werfen ist der sicherste Weg, ein Designdokument veralten zu lassen.

Dann sind da die 24 Kommandos. Sie sind eher ein Vokabular als ein Workflow:

craft fährt die komplette Sequenz aus Formfindung und Bauen mit visueller Iteration. critique prüft Hierarchie, Klarheit und emotionale Tonlage. audit kontrolliert Barrierefreiheit, Performance und Responsivität. polish richtet vor dem Release am Designsystem aus. bolder und quieter sind Richtungsanpassungen — verstärken oder zurücknehmen. harden kümmert sich um Fehlerzustände, i18n, Textüberlauf und Sonderfälle. typeset und layout reparieren die zwei Dinge, die agentengenerierte UIs am häufigsten falsch machen. live öffnet einen Browser und erzeugt Varianten eines benannten Elements direkt an Ort und Stelle.

Jedes davon lässt sich als eigenständiges Kürzel festnageln:

/impeccable pin audit

Das erzeugt /audit als Kommando auf oberster Ebene. Kleines Feature, großer Unterschied dabei, ob das Vokabular tatsächlich benutzt wird.

Der Detektor ist die interessante Ingenieursarbeit

Hier trennt sich Impeccable von den Stapeln von Prompt-Sammlungen: Die 62 Regeln brauchen kein Modell, keinen API-Key, keinen Agenten.

npx impeccable detect src/
npx impeccable detect index.html
npx impeccable detect --json .
npx impeccable detect --list-rules

Das heißt, es läuft in der CI. Ein Pull Request, der Bounce-Easing wieder einführt, einen verirrten Violett-Verlauf oder eine 14px graue Bildunterschrift auf Petrol zurückbringt, kann an einer Prüfung scheitern, ohne dass jemand Tokens bezahlt. Es gibt ein --github-Flag, das GitHub-Actions-Annotationen ausgibt — für die meisten Teams der einzige Integrationsdetail, das zählt.

Der Regelsatz hat klare Meinungen, so klar, dass es Leute ärgern wird, und die Doku sagt das offen. Die Anti-Pattern-Liste verbannt Arial, Inter und Systemvorgaben; verbannt reines Schwarz und reines Grau (immer getönt); verbannt Karten um alles herum und Karten in Karten; verbannt Bounce- und Elastik-Easing als veraltet; verbannt grauen Text auf farbigem Grund.

Einiges davon sind verteidigbare Handwerksargumente. Fließtext mit zu wenig Kontrast auf gesättigtem Grund ist ein Barrierefreiheitsfehler, der zufällig auch billig aussieht. Das Inter-Verbot ist Mode, und Moderegeln altern schlecht — dasselbe Dokument, das Inter verbannt, wird in drei Jahren wie ein Zeitstück wirken. Aber ein Linter ohne Meinungen ist nur ein Formatierer, und der Punkt an diesem hier ist, dass er eine Position hat.

Weil er deterministisch ist, ist er auch umgehbar. Jedes Team, das den Violett-Verlauf ausliefern will, kann eine Inline-Ausnahme ergänzen:

<!-- impeccable-disable overused-font: exported brand doc -->

Oder Ignorierungen global verwalten mit npx impeccable ignores add-value overused-font Inter --reason "Brand font". Das --reason-Flag leistet stille soziale Arbeit: Es macht die Ausnahme im Diff sichtbar.

Wie es sich in den Agenten einhängt

Welchen Installationsweg man wählt, entscheidet darüber, wie invasiv das wird. Für Claude Code, Copilot, Codex, Cursor und Grok Build schreibt install ein anbietereigenes Hook-Manifest. In Claude Code ist das .claude/settings.local.json, per gitignore ausgeschlossen und maschinenlokal. In Copilot ist es .github/hooks/impeccable.json, eingecheckt und mit Cloud-Agenten geteilt. In Cursor ist es .cursor/hooks.json, das bei postToolUse feuert, wenn eine Datei geschrieben wird.

Der Effekt: Der Detektor läuft auf den Änderungen des Agenten selbst und speist die Befunde in dessen Schleife zurück. Das ist ein anderer Mechanismus als „das Audit-Kommando ausführen, wenn man daran denkt“. Er fängt den Slop im Moment der Generierung ab, nicht im Review.

Der Preis ist der übliche: Hooks, die in die Repo-Konfiguration schreiben, tauchen im Code Review auf, und Codex-Nutzer müssen Projekt-Hooks nach der Installation explizit über /hooks genehmigen. Wenn dein Team klare Meinungen zu eingecheckter Tool-Konfiguration hat, gibt es den Submodul-Weg genau deshalb — git submodule add plus npx impeccable link --source=.impeccable --providers=claude,cursor hält das Werkzeug versioniert neben dem Code, den es regiert.

Was es nicht repariert

Drei Grenzen, die man benennen sollte.

Es kann dir nicht sagen, ob die Seite gut ist. Die 62 Regeln fangen Oberflächenmerkmale. Eine Seite kann alle bestehen und trotzdem keinen Standpunkt haben — das ist die tiefere Version des KI-Slop-Problems und die, die noch kein Linter gelöst hat.

Der live-Modus funktioniert nur auf einem lokalen Checkout. Er injiziert nichts in eine Produktionsseite, auch nicht über HTTPS. Vernünftig, aber es heißt: Die visuelle Iterationsschleife ist ein Werkzeug für die Entwicklung, nicht fürs Review.

Und das Vokabular hilft nur, wenn der Agent es liest. Impeccables eigene Formulierung ist ehrlich darin: Dass jedes Modell dasselbe Design produziert, liegt daran, dass jedes Modell auf denselben SaaS-Templates trainiert wurde. Eine Skill-Datei ist ein Anstupser gegen eine Trainingsverteilung, und Anstupser verlieren häufiger gegen Verteilungen, als irgendjemandem lieb ist.

Warum nicht einfach eine Checkliste schreiben?

Berechtigte Frage. Ein Styleguide in einer Markdown-Datei kostet nichts und leistet ungefähr dasselbe.

Der Unterschied ist die Durchsetzung. Eine Checkliste im Prompt ist ein Vorschlag: Das Modell liest sie, stimmt zu und produziert dann einen Violett-Verlauf, weil dieser Verlauf vierzigtausendmal in seinen Trainingsdaten stand. Eine deterministische Regel lässt einen Build scheitern. Das ist eine andere Kategorie von Druck, und es ist die einzige, die einen Deadline übersteht.

Der zweite Unterschied ist die Granularität. Eine Checkliste sagt „nutze gute Typografie“. Impeccables typeset-Kommando adressiert Hierarchie, Skala und Paarung konkret, und der Detektor hat Einzelregeln für Einzelfehler — die Rückmeldung kann also auf eine CSS-Zeile zeigen statt in Richtung Geschmack zu winken. Das ist das ganze Argument für Werkzeuge statt Dokumentation, und es gilt hier aus demselben Grund, aus dem es vor zwanzig Jahren für Linter galt.

Der dritte: Das Vokabular ist geteilt. bolder, quieter, distill, harden — auf diese Wörter können ein Designer und ein Agent beide reagieren. „Mach es poppiger“ nicht.

Warum es gerade jetzt trendet

Weil das Mengenproblem angekommen ist. Vor einem Jahr generierte ein Agent gelegentlich eine Landingpage. Heute produziert ein Team vierzig Varianten vor dem Mittagessen, und der Engpass hat sich von „können wir es bauen“ zu „können wir schnell genug sagen, welche davon gut ist“ verschoben.

Ein deterministischer Prüfer für die billigen Fehler ist der einzige Teil dieses Problems, der skaliert. Geschmack skaliert nicht. Zweiundsechzig regex-förmige Regeln zu Schriften und Easing skalieren, und sie als etwas auszuliefern, das ohne Modellaufruf in der CI läuft, ist die unglamouröseste und nützlichste Entscheidung im Repo.