yetone/kill-ai-slop

KI-Schrott entfernen

KI-Schrott ist auf eine bestimmte Weise hässlich: er häuft jeden möglichen Stil und jedes Detail an, ohne sich auf einen Fokus zu konzentrieren. Ein Verlauf, ein Leuchten, ein Maskottchen, Emojis, eine Wand aus leuchtenden Karten – jeder Standard wird gleichzeitig eingeschaltet, bis jedes Produkt aussieht wie dieselbe geschmacklose Vorlage. Es wirkt im Thumbnail wie „designt“ und zerfällt, sobald jemand genau hinsieht. Deine Aufgabe ist es, es auf etwas zurückzuführen, das ein Mensch tatsächlich auswählen würde.

Die Prinzipien, die bei jeder Korrektur gelten:

1. Entscheide, bevor du dekorierst. Jede visuelle Wahl muss erklärbar sein.
2. Ein Akzent, eine Stimme.
3. Hierarchie durch Größe und Abstand. Wörter einzufärben oder Schriftarten auszutauschen ist ein Abkürzungsweg.
4. Zuerst subtrahieren. Der erste Schritt weg vom Hässlichen ist das Entfernen von Dingen.
5. Spezifisch schlägt reißerisch im Text.
6. Dekoration muss etwas bedeuten – Symbole, Badges, Callouts sind Signale.

Arbeitsablauf

Befolge diese Schritte in der Reihenfolge. Nimm keine Massenänderungen vor, bevor der Benutzer den Bericht gesehen hat.

1. Umfang festlegen

Bestätige, was gescannt werden soll. Standardmäßig wird der App-/Seitenquellcode durchsucht (überspringe node_modules, dist, build, .git, vendor, Lockfiles, minifizierte Dateien). Frage, ob das Projekt mehrere Apps mischt.

2. Scannen

Führe den integrierten Scanner aus, der die Codebasis nach codespezifischen Signalen jedes Merkmals durchsucht und gruppierte Datei:Zeile-Treffer ausgibt:

node scripts/scan.mjs <root>          # menschenlesbarer Bericht
node scripts/scan.mjs <root> --json   # maschinenlesbar, zur Priorisierung

Er ist reines Node (keine Abhängigkeiten) und bearbeitet niemals Dateien. Verwende seine Ausgabe als Ausgangskarte, nicht als Evangelium – bestätige jeden Treffer durch Lesen des Codes.

Um einen Scan einzugrenzen: --only=01,06 / --skip=19 filtert nach Tell-ID, und --exclude=legacy entfernt Pfade (Teilstringübereinstimmung mit dem projektrelevanten Pfad). --rules=extra.mjs lädt zusätzliche projekt- oder sprachspezifische Tells (scripts/rules.ru.mjs ist ein mitgeliefertes russischsprachiges Beispiel und die Vorlage für deine eigenen). Treffer, die der Benutzer als beabsichtigt bestätigt hat, können im Quelltext mit deslop-ignore, deslop-ignore-next-line 06 oder deslop-ignore-file-Kommentaren markiert werden – bevorzuge die id-begrenzten Formen, damit neue Tells weiterhin erkannt werden.

3. Triage

Öffne für jeden Treffer die Datei und entscheide: Schrott vs. beabsichtigt. Dies ist der Schritt, der dieses Skill von einer Lint-Regel unterscheidet. Ein Farbverlauf, eine Serife oder ein Emoji kann eine echte, verteidigte Wahl sein. Behalte alles, was der Benutzer klar gewählt hat (Marken-Tokens, ein Logo, eine bewusste Illustration). Markiere nur die Standardfälle.

Lies references/taxonomy.md für die Beschreibung jedes Merkmals und warum es maschinell wirkt, sowie references/detection.md für die genauen Muster und ihre häufigen Fehlalarme.

4. Bericht

Gib dem Benutzer, bevor du etwas änderst, eine gruppierte Zusammenfassung: jedes Merkmal, die bestätigten Datei:Zeile-Treffer, einen Satz zur Begründung und den vorgeschlagenen Fix. Spiegele das Format wider:

slop  src/Hero.tsx:12   Indigo→Violett-Verlauf        → ein einheitlicher Akzent
slop  src/Hero.tsx:31   Clip-Text-Überschrift          → durchgehende Tinte, Größe erhöhen
slop  src/Note.tsx:8    border-l-4 Callout ×3         → 1 Randnotiz, Rest ist Fließtext
slop  copy.md:1         „nicht nur X – es ist Y“      → sag das spezifische Ding
→ 4 Gruppen, 11 Treffer.

Frage dann, welche Gruppen angewendet werden sollen oder ob mit allen fortgefahren werden soll.

5. Korrigieren

Wende die minimalste Änderung an, die das Merkmal entfernt, während Absicht und Funktion erhalten bleiben. Verwende references/fixes.md für das Vorher-Nachher-Muster pro Merkmal.

• Bevorzuge es, gemeinsame Tokens/Komponenten zu bearbeiten, anstatt jede Aufrufstelle einzeln anzufassen.
• Erfinde niemals neue Markenfarben; wenn eine Palette geändert werden muss, schlage Neutrale + den vorhandenen Akzent des Projekts vor und lass den Benutzer bestätigen.
• Behalte die Textbedeutung bei; mache ihn spezifisch, lösche ihn nicht einfach.
• Führe den Scanner nach der Korrektur erneut aus, um zu bestätigen, dass die Anzahl gesunken ist, und notiere alle Treffer, die du absichtlich stehen gelassen hast (mit Begründung).

Leitplanken

• Respektiere die Autorenschaft. Behandle unbekannte Dateien und bewusste Verzierungen als die Wahl einer Person. Wenn du dir unsicher bist, ob etwas Schrott ist, frage – entferne es nicht.
• Kleine, überprüfbare Diffs. Formatiere niemals unzusammenhängenden Code um. Führe niemals git add -A aus; stage nur explizite Dateien und lasse die laufende Arbeit anderer in Ruhe.
• Keine neuen Abhängigkeiten für diese Arbeit.
• Überprüfe nach Möglichkeit visuell. Wenn ein Dev-Server existiert, sieh dir das Vorher und Nachher an; ein bestandener Scan ist nicht dasselbe wie eine bessere Seite.

Referenzen

• references/taxonomy.md – die 35 Merkmale: was jedes ist, warum es Schrott ist, der Fix.
• references/detection.md – konkrete ripgrep-/Regex-Muster + Fehlalarme.
• references/fixes.md – Vorher-Nachher-Sanierungsmuster.
• scripts/scan.mjs – der abhängigkeitsfreie Scanner.