AI-Slop-Cleaner

AI-Slop-Cleaner (KI-Schrott-Bereiniger)

Verwenden Sie dieses Skill, um KI-generierten Code-Schrott zu entfernen, ohne den Umfang auszuweiten oder das beabsichtigte Verhalten zu ändern. Im OMC ist dies der begrenzte Bereinigungsworkflow für Code, der funktioniert, aber aufgebläht, repetitiv, schwach getestet oder überabstrahiert wirkt.

Wann verwenden

Verwenden Sie dieses Skill, wenn:

• der Benutzer explizit deslop, anti-slop oder AI slop sagt
• die Anfrage darin besteht, Code zu bereinigen oder umzugestalten, der laut, repetitiv oder übermäßig abstrakt wirkt
• eine Folgeimplementierung doppelte Logik, toten Code, Wrapper-Ebenen, Boundary-Leaks oder schwache Regressionsabdeckung hinterlassen hat
• der Benutzer eine nur für Prüfer gedachte Anti-Schrott-Runde über --review wünscht
• das Ziel eine Vereinfachung und Bereinigung ist, nicht die Lieferung neuer Funktionen

Wann nicht verwenden

Verwenden Sie dieses Skill nicht, wenn:

• die Aufgabe hauptsächlich der Bau einer neuen Funktion oder eine Produktänderung ist
• der Benutzer einen breiten Redesign anstelle einer schrittweisen Bereinigung wünscht
• die Anfrage eine allgemeine Umgestaltung ohne Vereinfachungs- oder Anti-Schrott-Absicht ist
• das Verhalten zu unklar ist, um es mit Tests oder einem konkreten Überprüfungsplan zu schützen

OMC-Ausführungshaltung

• Verhalten bewahren, es sei denn, der Benutzer fordert ausdrücklich Verhaltensänderungen an.
• Verhalten zuerst mit fokussierten Regressionstests sichern, wann immer praktikabel.
• Vor dem Bearbeiten von Code einen Bereinigungsplan schreiben.
• Löschung der Hinzufügung vorziehen.
• Vorhandene Dienstprogramme und Muster wiederverwenden, bevor neue eingeführt werden.
• Neue Abhängigkeiten vermeiden, es sei denn, der Benutzer fordert sie ausdrücklich an.
• Diffs klein, reversibel und geruchszentriert halten.
• Prägnant und evidenzdicht bleiben: Inspizieren, Bearbeiten, Verifizieren, Berichten.
• Neue Benutzeranweisungen als lokale Bereichsaktualisierungen behandeln, ohne frühere nicht widersprechende Einschränkungen fallen zu lassen.

Verwendung eines begrenzten Datei-Umfangs

Dieses Skill kann auf eine explizite Dateiliste oder einen Umfang geänderter Dateien beschränkt werden, wenn der Aufrufer die sichere Bereinigungsoberfläche bereits kennt.

• Gute Wahl: oh-my-claudecode:ai-slop-cleaner skills/ralph/SKILL.md skills/ai-slop-cleaner/SKILL.md
• Gute Wahl: Eine Ralph-Sitzung, die nur die in dieser Sitzung geänderten Dateien übergibt
• Denselben regression-sicheren Workflow beibehalten, auch wenn der Umfang eine kurze Dateiliste ist
• Den Umfang geänderter Dateien nicht stillschweigend auf eine breitere Bereinigungsarbeit ausweiten, es sei denn, der Benutzer fordert dies ausdrücklich an

Ralph-Integration

Ralph kann dieses Skill als begrenzte Überprüfungs-Bereinigung nach der Bearbeitung aufrufen.

• In diesem Workflow läuft die Bereinigung im Standardmodus (nicht --review)
• Der Bereinigungsumfang sind nur die in der Ralph-Sitzung geänderten Dateien
• Nach dem Bereinigungsdurchlauf führt Ralph die Regressionsüberprüfung erneut durch, bevor der Vorgang abgeschlossen wird
• --review bleibt der Nur-Prüfer-Nachverfolgungsmodus, nicht der standardmäßige Ralph-Integrationspfad

Überprüfungsmodus (--review)

--review ist ein Nur-Prüfer-Durchlauf, nachdem die Bereinigungsarbeit entworfen wurde. Er dient dazu, eine explizite Trennung von Schreiber und Prüfer für Anti-Schrott-Arbeiten zu erhalten.

• Schreiber-Durchlauf: Die Bereinigungsänderungen vornehmen, wobei das Verhalten durch Tests gesichert ist.
• Prüfer-Durchlauf: Den Bereinigungsplan, die geänderten Dateien und die Überprüfungsnachweise inspizieren.
• Derselbe Durchlauf darf nicht sowohl schreiben als auch sich selbst für eine folgenreiche Bereinigung ohne einen separaten Überprüfungsschritt genehmigen.

Im Überprüfungsmodus:

1. Beginnen Sie nicht mit dem Bearbeiten von Dateien.
2. Überprüfen Sie den Bereinigungsplan, die geänderten Dateien und die Regressionsabdeckung.
3. Prüfen Sie insbesondere auf:
   • übrig gebliebenen toten Code oder ungenutzte Exporte
   • doppelte Logik, die hätte konsolidiert werden sollen
   • unnötige Wrapper oder Abstraktionen, die immer noch Grenzen verwischen
   • fehlende Tests oder schwache Überprüfung für beibehaltenes Verhalten
   • Bereinigung, die das Verhalten ohne Absicht verändert zu haben scheint
4. Erstellen Sie ein Prüferurteil mit erforderlichen Folgemaßnahmen.
5. Geben Sie notwendige Änderungen an einen separaten Schreiber-Durchlauf zurück, anstatt sie in einem Schritt zu beheben und zu genehmigen.

Workflow

1. Aktuelles Verhalten zuerst schützen

   • Identifizieren Sie, was gleich bleiben muss.
   • Fügen Sie die engsten Regressionstests hinzu oder führen Sie sie aus, bevor Sie Änderungen vornehmen.
   • Wenn Tests nicht zuerst kommen können, dokumentieren Sie den Überprüfungsplan explizit, bevor Sie Code berühren.

2. Vor dem Code einen Bereinigungsplan schreiben

   • Begrenzen Sie den Durchlauf auf die angeforderten Dateien oder den Funktionsbereich.
   • Listen Sie die konkreten Gerüche auf, die entfernt werden sollen.
   • Ordnen Sie die Arbeit von der sichersten Löschung bis hin zur riskanteren Konsolidierung.

3. Den Schrott vor dem Bearbeiten klassifizieren

   • Duplikation – wiederholte Logik, Kopieren-und-Einfügen-Zweige, redundante Helfer
   • Toter Code – ungenutzter Code, unerreichbare Zweige, veraltete Flags, Debug-Überbleibsel
   • Unnötige Abstraktion – Durchgangs-Wrapper, spekulative Indirektion, einzigartige Helfer-Ebenen
   • Boundary-Verletzungen – versteckte Kopplung, falsch platzierte Verantwortlichkeiten, Imports oder Seiteneffekte auf der falschen Ebene
   • Fehlende Tests – Verhalten nicht gesichert, schwache Regressionsabdeckung, Lücken bei Grenzfällen
   • UI/Design-Standards – generische visuelle Muster, die eine KI-gebaute Oberfläche ungeprüft erscheinen lassen

UI/Design-Prüfer-Checkliste

Verwenden Sie diese als Prüfaufforderungen, nicht als absolute Verbote. Behalten Sie bewusste Marken-, Zugänglichkeits-, Produktdichte- oder Designsystem-Entscheidungen bei, wenn sie eine klare Begründung haben.

• Koreanische Lesbarkeit: Kennzeichnen Sie Fließtext um 11–12 px; koreanischer Fließtext benötigt im Allgemeinen mindestens 14 px, es sei denn, eine validierte Ausnahme für dichte Daten gilt.
• Schattenzurückhaltung: Hinterfragen Sie Kastenschatten auf jeder Oberfläche, jedem Logo, Hintergrund, jeder Karte oder jedem Icon; halten Sie Schatten nur dort, wo sie Ebenen oder Interaktion verdeutlichen.
• Inhaltshierarchie: Entfernen Sie wiederholtes Eyebrow/Titel/Beschreibung/extra <p>-Füllmaterial, wenn der Titel die Botschaft bereits trägt; vermeiden Sie generische Emoji-Badges, es sei denn, sie sind Teil der Produktstimme.
• Palettenbegründung: Fordern Sie Standard-KI-Blau-/Lila-Paletten heraus, insbesondere Tailwind-ähnliche #3B82F6, wenn keine Marken- oder Systembegründung existiert.
• Layout-Rhythmus: Vermeiden Sie übermäßig perfekte 3- oder 4-spaltige einheitliche Raster, wenn der Produktkontext von Rhythmus, Betonung, Asymmetrie, Karussell-/Bento-Behandlung oder variierenden Kartengewichten profitiert.
• Verlaufzurückhaltung: Reduzieren Sie extreme Verläufe, es sei denn, die Marke besitzt diese visuelle Sprache bewusst.

4. Einen geruchszentrierten Durchlauf nach dem anderen ausführen

   • Durchlauf 1: Löschung von totem Code
   • Durchlauf 2: Entfernung von Duplikaten
   • Durchlauf 3: Bereinigung von Benennung und Fehlerbehandlung
   • Durchlauf 4: Testverstärkung
   • Nach jedem Durchlauf eine gezielte Überprüfung erneut ausführen.
   • Nicht zusammenhängende Umgestaltungen nicht in denselben Bearbeitungssatz bündeln.

5. Die Qualitätsprüfungen ausführen

   • Regressionstests grün halten.
   • Die relevanten Lint-, Typprüfungs- und Unit-/Integrationstests für den berührten Bereich ausführen.
   • Vorhandene statische oder Sicherheitsprüfungen ausführen, wenn verfügbar.
   • Wenn eine Prüfung fehlschlägt, das Problem beheben oder die riskante Bereinigung zurückziehen, anstatt sie zu erzwingen.

6. Mit einem evidenzdichten Bericht abschließen

   • Geänderte Dateien
   • Vereinfachungen
   • Verhaltenssicherung / Überprüfungslauf
   • Verbleibende Risiken

Verwendung

• /oh-my-claudecode:ai-slop-cleaner <target>
• /oh-my-claudecode:ai-slop-cleaner <target> --review
• /oh-my-claudecode:ai-slop-cleaner <file-a> <file-b> <file-c>
• Von Ralph: Führen Sie die Bereinigung nur auf den in der Ralph-Sitzung geänderten Dateien aus, kehren Sie dann für die Regressionsüberprüfung nach der Bereinigung zu Ralph zurück

Gute Beispiele

Gut: deslop dieses Modul: zu viele Wrapper, doppelte Helfer und toter Code

Gut: Bereinige den KI-Schrott in src/auth und schärfe die Grenzen, ohne das Verhalten zu ändern

Schlecht: Forme auth um, um SSO zu unterstützen

Schlecht: Bereinige die Formatierung