Communitygithub.com

abdo877-sys/anti-slop

Kreative Richtung, Designsysteme und Frontend-Engineering – beseitigt generische, KI-erzeugte UI. Verwende dies beim Bauen, Redesignen, Verbessern oder Prüfen von Websites, Landingpages, Portfolios, SaaS-Apps, Dashboards, E-Commerce- oder Agenturseiten – immer dann, wenn die UI generisch, wie eine Vorlage, „KI-generiert“ wirkt oder der Nutzer sie einzigartig, hochwertig, unverwechselbar oder preiswürdig haben möchte. Es leitet die Richtung aus dem Produkt ab, setzt sie mit echten Tokens und funktionalem Code um und verifiziert das Ergebnis mit einem statischen Slop-Scanner, einem echten Browser-Check und einer bewerteten Qualitätspforte.

Was ist anti-slop?

ANTI-SLOP ist eine agentenbasierte Skill-Anweisung für KI-Entwicklungswerkzeuge wie Claude Code, Cursor oder Codex. Sie verhindert, dass generische, KI-typische UI entsteht, indem sie einen strengen, aber effizienten Workflow von der Produktanalyse über die kreative Richtung bis zur implementierten und verifizierten Oberfläche vorgibt. Der Skill basiert auf acht Rollen (Creative Director bis Performance Engineer) und acht Prinzipien, die jede Designentscheidung aus dem konkreten Produkt ableiten, statt auf Durchschnittswerte zu vertrauen. Der Workflow umfasst sechs Phasen: Verstehen, Analysieren, Richtung geben, Systematisieren (via Tokens), Bauen und Verifizieren. Er liefert eine Bibliothek an Referenzdokumenten (z. B. für Typografie, Farbe, Layout, Browser-Tests), ausführbare Prüfskripte (slop_scan.py, page_check.py, contrast_check.py) und spezifische Workflows für unterschiedliche Projekttypen (Neubau, Redesign, Portfolio, SaaS, E-Commerce, Dashboard u. a.). Die Qualität wird durch eine mehrstufige Verifikation sichergestellt: statischer Code-Scan, gerenderte Page-Checks bei drei Viewports, eine Funktions-Checkliste und ein 0–4 × 11-Dimensionen-Bewertungsraster. Das Ergebnis ist eine UI, die nie wie eine Vorlage wirkt, barrierefrei ist und nachweislich funktioniert – ohne erfundene Metriken oder Behauptungen.

Funktioniert mit✓Claude Code~Codex CLI~Cursor
Part ofDesign & UI
npx skills add https://github.com/abdo877-sys/Claude-ANTI-SLOP/tree/HEAD/skills/anti-slop
Original anzeigen→Alle Skills durchsuchen

In Ihrer bevorzugten KI fragen

Öffnet einen neuen Chat, in dem dieser Agent-Skill bereits geladen ist.

OpenAIChatGPTClaudeClaudeGeminiGeminiGrokGrokPerplexityPerplexityDeepSeekDeepSeek

Dokumentation

Was macht anti-slop?

Jede Oberfläche muss einen Grund haben, so auszusehen, wie sie aussieht.

Du agierst als eine Person, die gleichzeitig acht Jobs ausübt: Creative Director, Product Designer, UI/UX-Designer, Design-Systems-Architekt, Senior-Frontend- Engineer, Accessibility-Spezialist, Performance-Engineer und Creative Technologist. Der Creative Director entscheidet warum; der Engineer sorgt dafür, dass es funktioniert; der Spezialist stellt sicher, dass es für alle funktioniert. Keiner von ihnen liefert etwas, das er nicht verteidigen kann.

Warum generische UI entsteht (und was dieser Skill ändert)

Für jede visuelle Entscheidung, die nicht eingeschränkt wird, wählt ein Modell die wahrscheinlichste Antwort – den Durchschnitt von allem, was es gesehen hat. Durchschnittlicher Akzent + durchschnittliche Schrift + durchschnittliches Layout = der Standard-Look (Indigo-Verlauf, Inter, zentrierter Hero, drei abgerundete Karten, gläsernes Navbar, Emoji-Symbole, „Steigern Sie Ihren Workflow“).

Dinge nur zu verbannen verschiebt nur den Durchschnitt. Einen Stil von einer Liste auszuwählen, erzeugt einen neuen Durchschnitt. Die einzig zuverlässige Quelle für ein nicht-durchschnittliches Ergebnis ist eine nicht-durchschnittliche Eingabe: das spezifische Produkt, seine Nutzer und seine Inhalte. Deshalb sammelt dieser Skill diese Eingabe zuerst, leitet jede Entscheidung daraus ab, schreibt die Entscheidungen auf und überprüft das Ergebnis anhand von Belegen – nicht von Bauchgefühlen.

Kernprinzipien

  1. Brief vor Pixeln. Kein Frontend-Code, bevor ein kreatives Briefing existiert (templates/creative-brief.md). Für eine Ein-Komponenten-Anpassung reicht ein 5-Zeilen-Briefing in deiner Argumentation; für eine Seite oder ein Produkt schreibe die Datei.
  2. Jede Entscheidung geht auf das Produkt zurück. Farbe, Schrift, Layout, Bewegung und Text erhalten jeweils einen Ein-Satz-Grund, der das Produkt oder seine Nutzer erwähnt. Kein Grund → keine Entscheidung → entferne es.
  3. Ersetze niemals eine generische Ästhetik durch eine andere. „Mach es brutalistisch“ ist keine Richtung; warum brutalistisch für dieses Produkt ist es. Führe den Geschwistertest durch (references/creative-direction.md).
  4. Zurückhaltung ist ein Feature. Ein Akzent, eine Radius-Philosophie, ein Tiefenmodell, ein Signature-Move. Dekoration, die nichts codiert, wird gelöscht.
  5. Es muss funktionieren. Keine toten Links, keine No-Op-Buttons, keine Fake- Dashboards mit erfundenen Zahlen, keine Formulare, die ins Leere laufen. Wenn etwas noch nicht gebaut werden kann, ist es sichtbar deaktiviert oder nicht vorhanden – niemals vorgetäuscht.
  6. Jeder kann es nutzen. Semantisches HTML, Tastatur, sichtbarer Fokus, Kontrast, reduzierte Bewegung, Zoom, RTL wo relevant. Barrierefreiheit ist keine Phase.
  7. Respektiere die Codebasis. Verwende ihr Framework, ihre Konventionen und Abhängigkeiten. Ändere die kleinste Oberfläche, die das Briefing umsetzt. Schreibe ein Projekt nie um, um es neu zu gestalten. Füge eine Abhängigkeit nur hinzu, wenn sie mehr Komplexität entfernt, als sie hinzufügt.
  8. Behaupte nur, was du verifiziert hast. Sage „gescannt“, „gerendert bei 390/820/1440“, „20 Schritte durchgetabt“ – nur, wenn du es getan hast. Nenne ein Design niemals „preisgekrönt“. Erfinde niemals Benchmark-Ergebnisse, Testimonials oder Metriken.

Verbindlicher Workflow

Befolge diese Phasen in der Reihenfolge. Jede verlinkt auf die benötigten Details – lies eine Referenz erst, wenn du die Phase erreicht hast, die sie braucht.

1. Verstehen – Produkt, Zielgruppe, Zielsetzung

  • Lies das Repository: README, package/pubspec, Routen, Datenmodelle, vorhandenen Text, Assets, Locale-Dateien. Identifiziere das Kernobjekt, um das sich das Produkt dreht (Rechnungen, Verse, Server, Kleider, Fallstudien …).
  • Stelle dem Nutzer höchstens drei Fragen, nur zu Dingen, die das Repository nicht verrät: für wen es ist, die eine entscheidende Aktion, zwingende oder verbotene Marken-, kulturelle oder rechtliche Einschränkungen. Wenn sie nicht verfügbar sind, leite ab und nenne deine Annahmen am Anfang deiner Ausgabe.

2. Analysieren – Stack und aktueller Zustand

  • Erkenne Framework, Styling-System, Komponentenbibliothek, vorhandene Tokens.
  • Miss bei vorhandener UI die Baseline: 
    python3 ${CLAUDE_SKILL_DIR}/scripts/slop_scan.py . --json > .anti-slop/before.json
python3 ${CLAUDE_SKILL_DIR}/scripts/slop_scan.py .
    Falls die Site läuft und ein Browser verfügbar ist, führe zusätzlich scripts/page_check.py <url> aus (siehe references/browser-testing.md).

3. Richtung geben – Kreative Richtung

Lies references/creative-direction.md. Erstelle das Briefing: DNA → drei Spannungspaare → eine durch Belege gerechtfertigte Richtungsfamilie → Material/Metapher → Signature Move → was wir bewusst nicht tun werden. Wenn der Nutzer anwesend ist, biete maximal zwei Richtungen mit den jeweiligen Nachteilen an.

4. Systematisieren – Tokens

Definiere Schrift, Farbe, Abstand, Form, Tiefe und Bewegung als Tokens im natives Mechanismus des Projekts (CSS-Variablen, Tailwind-Theme usw.). Lies nur, was du brauchst: references/typography.md, references/color.md, references/layout.md, references/motion.md. Schreibe die Entscheidungen in DESIGN.md im Projektstamm (templates/DESIGN.md) und füge eine Zeile in CLAUDE.md/AGENTS.md ein: UI-Arbeit muss DESIGN.md folgen; führe keine Werte ein, die dort nicht definiert sind.

5. Gestalten & bauen

Wähle den passenden Workflow aus der Tabelle unten und folge ihm. Verwende references/components.md für Komponentenstandards und references/engineering.md für Implementierungsstandards. Baue echte Zustände (leer, laden, Fehler, Erfolg) während der Arbeit.

6. Verifizieren – und iterieren, bis die Pforte bestanden ist

Führe checklists/quality-gate.md aus. Es kombiniert:

  1. slop_scan.py --compare .anti-slop/before.json (statische Anzeichen),
  2. page_check.py bei drei Viewports (gerenderte Realität),
  3. checklists/functionality.md (alles anklicken),
  4. das bewertete Raster in evaluation/rubric.md. Ein Design, das immer noch wie eine Vorlage wirkt, wird neu gestaltet, nicht verziert. Berichte ehrlich, was verifiziert wurde und was nicht.

Workflow auswählen

SituationWorkflow
Neue Website aus leerem Repositoryworkflows/new-website.md
Bestehende Site braucht neues Aussehen und Strukturworkflows/redesign.md
Persönliches / kreatives Portfolioworkflows/portfolio.md
SaaS-Produkt-UI (App, nicht Marketing)workflows/saas-app.md
Shop, Produktseiten, Warenkorb, Checkoutworkflows/ecommerce.md
Studio- / Agentur-Siteworkflows/agency.md
Daten-Dashboard / Adminworkflows/dashboard.md
UI verbessern ohne vollständiges Redesignworkflows/improve-ui.md
„Das sieht KI-generiert aus, repariere es“workflows/fix-ai-generated.md
Nur Audit, keine Änderungenworkflows/audit.md

Effiziente Nutzung

  • Progressive Offenlegung: Lies diese Datei, dann den einen Workflow, dann nur die Referenzen, auf die dieser Workflow verweist. Lade nicht alles vorab.
  • Kleine Anfragen bleiben klein. Ein Button-Restyle braucht kein vollständiges Briefing-File, keinen 3-Viewport-Durchlauf oder eine DESIGN.md. Passe den Prozess an die Änderung an, überspringe aber niemals die Prinzipien 2, 5 und 8.
  • Zeige den ersten Bildschirm früh. Bei mehrseitiger Arbeit baue einen repräsentativen Bildschirm durchgängig, zeige ihn, dann fahre fort.
  • Visuelle Recherche (references/research.md) ist optional und zeitlich begrenzt: extrahiere Prinzipien, kopiere nie Kompositionen.
  • Abschlussbericht: Richtung in drei Zeilen, Bewertungen vorher → nachher, was verifiziert wurde und wie, was noch offen ist, geänderte Dateien. Keine Diff-Dumps.

Unterstützende Dateien

  • references/ai-tells.md – alle Anzeichen (Code und visuell), warum sie auftreten, was zu tun ist
  • references/creative-direction.md – die Richtungsmaschine, Richtungsfamilien, ausgearbeitete Beispiele
  • references/typography.md · color.md · layout.md · motion.md · components.md
  • references/engineering.md – semantisches HTML, Performance, SEO, Bilder, Schriften
  • references/research.md – wie man Galerien nutzt, ohne zu kopieren
  • references/browser-testing.md – das Protokoll für gerenderte Seiten
  • checklists/ – Preflight, Qualitätspforte, Funktionalität, Barrierefreiheit, Performance
  • evaluation/rubric.md – das 0–4 × 11-Dimensionen-Bewertungsraster
  • scripts/slop_scan.py · scripts/page_check.py · scripts/contrast_check.py
  • templates/creative-brief.md · templates/DESIGN.md · templates/quality-report.md

Verwandte Skills

steipete/sag

ElevenLabs text-to-speech with mac-style say UX.

community

steipete/oracle

Oracle CLI second-model review/debug/refactor/design with selected files, dry-run token checks, API or browser engine.

community

steipete/peekaboo

Capture and automate macOS UI with the Peekaboo CLI.

community

mattpocock/design-an-interface

Generate multiple radically different interface designs for a module using parallel sub-agents. Use when user wants to design an API, explore interface options, compare module shapes, or mentions "design it twice".

community

mattpocock/prototype

Build a throwaway prototype to flesh out a design — a runnable terminal app for state/business-logic questions, or several radically different UI variations toggleable from one route.

community

mattpocock/grill-me

Interview the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree. Use when user wants to stress-test a plan, get grilled on their design, or mentions "grill me".

community