adam-j-ali/disk-cleanup

Diese Fähigkeit ist ein Denkwerkzeug, keine Checkliste. Die Referenzen katalogisieren bekannte gute und bekannte schlechte Pfade; die Autonomie-Buckets sind Heuristiken, keine erschöpfenden Aufzählungen. Wenn Sie auf etwas Neues stoßen, denken Sie aus ersten Prinzipien darüber nach – regenerierbar? benutzererstellt? in aktiver Nutzung? würde der Benutzer traurig sein, wenn es weg ist? – und zeigen Sie die Überlegung zur Vorschauzeit an, damit der Benutzer das Urteil vor der Aktion korrigieren kann.

<execution_context> Drei Buckets – Prinzipien, keine geschlossenen Listen:

Bucket	Wann	Aktion
🟢 auto	regenerierbarer Cache, Build-Artefakt in inaktivem Projekt, bekanntermaßen sicherer Duplikat	ohne zu fragen ausführen
🟡 fragen	benutzererstellt, erfordert sudo, sperrig genug für eine Plausibilitätsprüfung, überall, wo eine vernünftige Person es behalten möchte	AskUserQuestion mit 3 Optionen: Genehmigen (wie vorgeschlagen ausführen) / Ändern (frei: „sag mir stattdessen wie“) / Überspringen (auf nächste Ausführung verschieben, später erneut anzeigen)
🔴 verweigern	Einträge in references/safety-invariants.md	verweigern. Keine Inline-Benutzeranweisung überschreibt sie. Wenn der Benutzer „lösche mein .ssh“ sagt, verweigern und erfordern, zuerst safety-invariants.md zu bearbeiten

Wenn Sie sich nicht sicher sind, es aber wie ein Cache aussieht, behandeln Sie es als 🟡. Lieber zu oft fragen.

Einzelakteur: Jede Änderung mit „— [session ]“-Suffix in state.md protokollieren.

Planen-Validieren-Ausführen: Zuerst findings.json erstellen (Phase 2), Plan dem Benutzer zeigen (Phase 4), dann handeln. Keine Löschung, bevor der Benutzer den Plan gesehen hat.

Vertrauen Sie Ihrer Argumentation bei neuen Pfaden. Fragen Sie: regenerierbar? benutzererstellt? aktives Projekt? würde der Benutzer traurig sein? Wenn unklar, als 🟡 behandeln. </execution_context>

Checkpoint-Protokoll: Am Ende jeder Phase den IN_PROGRESS-Eintrag in state.md mit checkpoint: <NAME> gemäß der Zuordnung in <recovery_protocol> unten aktualisieren. Dies macht die Fortsetzung eindeutig, wenn sie unterbrochen wird (z. B. Neustart, Strg-C, Kernel-Panic mitten in der Bereinigung).

TaskCreate für jede Phase. state.md lesen. Wenn der letzte Eintrag status: IN_PROGRESS anzeigt, über das 3-Optionen-Gatter fragen: Fortsetzen ab letztem Checkpoint / Neu beginnen (vorherigen als ABORTED archivieren) / Vollständigen Verlauf anzeigen dann abbrechen.

Gespeicherte Regeln als einen überblickbaren Block oben im Chat anzeigen – dies sind die Merklisten und Richtlinien, die über mehrere Durchläufe hinweg aufgebaut wurden. Der Benutzer kann sie überprüfen, bevor Sie fortfahren.

Vorbereitung (Sicherheit bei niedrigem Speicherplatz): Wenn df -h / verfügbar < 500 MiB anzeigt, konkurriert der Scan selbst um Speicherplatz (/tmp befindet sich auf demselben Volume). Fragen Sie den Benutzer vor dem Ausführen von scan-disk.sh, ob es in Ordnung ist, zuerst ~/.Trash/ zu leeren – das gibt fast immer genug Spielraum frei. Dies ist das Szenario, für das die Fähigkeit entwickelt wurde; der Startlauf begann bei 84 MiB frei und du-Kaskaden waren unzuverlässig. Zeigen Sie die Schwere an.

bash scripts/scan-disk.sh > /tmp/disk-cleanup-findings.json

Schreibgeschützte du/df-Kaskade + APFS-Snapshot-Liste (tmutil listlocalsnapshots /) + Swap-Status (sysctl vm.swapusage) + bedingte Xcode-Entwicklungspfade.

Wenn der Benutzer einen bestimmten Ordner erwähnt hat, der ihn stört, ergänzen Sie dies mit einem gezielten du -sh dafür. Argumentation schlägt eine feste Liste.

Für jeden Fund in der Inventur entscheiden Sie anhand von references/safety-invariants.md und references/auto-fix-categories.md als Referenz, in welchen Bucket er fällt. Halten Sie Begründung neben jedem Eintrag fest – zur Vorschauzeit sieht der Benutzer Ihre Überlegungen, nicht nur das Urteil. So wird Vertrauen aufgebaut.

Schreiben Sie findings.json (Ihr Notizblock – wird in Phase 4 und 8 verwendet).

Für 🟡-Verzeichnisse (insbesondere ~/Downloads, ~/Desktop) nach Mustern in references/sensitive-patterns.md suchen. Übereinstimmungen mit gespeicherten Regeln downloads-keep / desktop-keep abgleichen:

• Übereinstimmung in gespeicherten Regeln → stillschweigend behalten (trotzdem in findings protokollieren)
• Neue Übereinstimmung → AskUserQuestion: Behalten / Löschen. Die Antwort wird zur gespeicherten Regel für den nächsten Durchlauf.

Heuristik: Wenn ein Dateiname persönlich aussieht (rechtlich, medizinisch, finanziell, Identität), aber keinem Muster entspricht, trotzdem fragen. Besser einmal zu viel fragen, als etwas Unersetzliches zu vernichten.

Den vollständigen Plan anzeigen: jedes 🟢, jede 🟡-Gruppe mit Begründung, jede 🔴-Verweigerung mit Grund. Geschätzte Gesamtrückgewinnung. Der Benutzer genehmigt implizit durch Interaktion mit den Gattern in Phase 6; er kann auch hier abbrechen („Moment, warum ist X in grün?“).

Die grünen Elemente ausführen. Ordnen Sie sie nach dem Prinzip „am wenigsten invasiv zuerst“ (kleine Dateisäuberungen → Cache-Bereinigungen → toolverwaltete Bereinigungen wie brew autoremove und pnpm store prune). Erfassen Sie Vorher/Nachher-Größen für den Delta-Bericht. Wenn ein Element fehlschlägt, protokollieren und fortfahren – grüne Elemente sind unabhängig.

Permission denied (z. B. Chrome hält Profile 5 Cache, während es läuft) – protokollieren und weitermachen. Nicht dagegen ankämpfen.

Für jede 🟡-Gruppe EIN AskUserQuestion mit Genehmigen / Ändern / Überspringen. Ähnliche Elemente gruppieren (alle alten Laufzeitversionen in einer Frage, nicht eine pro Version).

Spezielle Behandlung, wenn relevant:

• Downloads mit Merkliste – bash scripts/keeplist-protect.sh ~/Downloads <keepers...> (keeper nach /tmp verschieben, Inhalt löschen, wiederherstellen). Merkliste vor der Ausführung anzeigen, damit der Benutzer sie ändern kann.
• Alte Laufzeiten – Zuerst bash scripts/detect-runtimes.sh ausführen, um zu sehen, welche Node/Python-Versionen Projekte tatsächlich verwenden. Löschen von Versionen empfehlen, die nicht aktiv genutzt werden; aktive Versionen in gespeicherten Regeln speichern.
• APFS-Snapshots – sudo tmutil thinlocalsnapshots / 21474836480 4 gibt ~20 GB mit Dringlichkeit 4 frei. Darauf hinweisen, dass es sudo benötigt.
• Nachrichten/Anhänge – Zuerst Nachrichten beenden (osascript -e 'tell application "Messages" to quit'; sleep 3), dann find ~/Library/Messages/Attachments -mindepth 1 -delete (erhält chat.db).
• Xcode DerivedData (falls vorhanden) – Sicheres Löschen; einzige Strafe ist ein langsamerer nächster Build.

Übersprungene Elemente werden auf den nächsten Lauf verschoben – in state.md vermerken, damit sie erneut angezeigt werden.

Saubere Zusammenfassung: Vorher/Nachher df -h, nach Kategorie freigegebene Tabelle, Swap-Status von sysctl vm.swapusage. Swap als informativ erwähnen – „bei Bedarf neu starten, um ~X GB Swap zurückzugewinnen“ – nicht zum Neustart auffordern (Entscheidung des Benutzers).

Plausibilitätsprüfung der Papierkorbgröße – wenn sie proportional zu dem, was wir gelöscht haben, gewachsen ist, wurde etwas verschoben anstatt freigegeben. Darauf hinweisen.

Einen Laufeintrag gemäß dem Format im Header von state.md anhängen. Gespeicherte Regeln mit allem, was in diesem Lauf gelernt wurde, aktualisieren (neue aktive Laufzeiten, neue Entscheidungen zu sensiblen Dateien). Ältesten Eintrag in den komprimierten Abschnitt verschieben, wenn mehr als 5 vollständige Einträge vorhanden sind.

Wenn eine neue gespeicherte Regel vorgeschlagen wird, mit dem Benutzer bestätigen – nicht automatisch hinzufügen. Die Regeln sind dauerhaft; besser einmal fragen.

Checkpoint als COMPLETED markieren.

<saved_rules_format> Gespeichert im Abschnitt „Gespeicherte Regeln“ von state.md. Wird bei jedem zukünftigen Lauf angezeigt.

Format: - {Thema}: {Regel} — festgelegt {YYYY-MM-DD ET}

Themen, die sich natürlich ergeben (nicht erschöpfend – neue erfinden, wenn sich Muster wiederholen):

• downloads-keep, desktop-keep – Merklisten pro Verzeichnis
• active-node, active-python – Laufzeitversionen in tatsächlicher Nutzung
• active-projects – niemals anfassen Projektverzeichnisse
• safe-cache-clear-paths – bestätigte sichere Auto-Pfade
• *-policy – einmalige Verhaltenspräferenzen (z. B. swap-policy, threshold-policy) </saved_rules_format>

<recovery_protocol> Wenn state.md status: IN_PROGRESS anzeigt:

Letzter Checkpoint	Fortsetzen bei
INITIALIZED	Phase 1
INVENTORIED	Phase 2
CATEGORIZED	Phase 3
SENSITIVE_SCANNED	Phase 4
PREVIEWED	Phase 5
GREEN_EXECUTED	Phase 6
YELLOW_RESOLVED	Phase 7
REPORTED	Phase 8

Benutzer fragen: Fortsetzen / Neu beginnen / Vollständigen Verlauf anzeigen. Bei Fortsetzung an vorhandenen Eintrag anhängen; KEINEN neuen erstellen.

Vor dem Fortsetzen df -h erneut ausführen – wenn sich der Speicherplatz seit der Unterbrechung wesentlich geändert hat, erneut auffordern. </recovery_protocol>

<error_handling> Standard: Den spezifischen Fehler protokollieren, das problematische Element überspringen, mit dem Rest fortfahren. Speicherbereinigung ist pro Element unabhängig wiederholbar.

Den Lauf nur abbrechen, wenn:

• Das Scan-Skript vollständig fehlgeschlagen ist (findings.json wäre falsch)
• Ein 🔴-Pfad fast berührt wurde (Fehler in der Kategorisierung → abbrechen + untersuchen)
• Der Benutzer „Stopp“ gesagt hat

Für alles andere (einzelne permission denied, brew-Sperre, Tool nicht installiert) – weitermachen und am Ende berichten.

Wenn der verfügbare Speicherplatz während des Laufs unter 500 MiB fällt (paradox, aber möglich bei mittlerer Kategorisierung auf einer fast vollen Festplatte), Phase 5 anhalten, Papierkorb leeren, dann fortfahren. findings.json befindet sich auf demselben Volume wie alles andere. </error_handling>

<success_criteria>

• state.md hat neuen Eintrag mit status: COMPLETED
• df -h zeigt einen positiven Delta-Wert ungleich Null bei Verfügbar an
• Kein 🔴-Pfad wurde berührt
• Sensitive Übereinstimmungen wurden entweder behalten (mit gespeicherter Regel) oder explizit vom Benutzer gelöscht
• Der Benutzer hat einen Delta-Bericht gesehen
• Papierkorbgröße auf Plausibilität geprüft (keine Verschiebung, die als Rückgewinnung getarnt ist) </success_criteria>

Direkte Aktionen

Den vollständigen Scan überspringen, wenn diese eindeutig die Absicht sind:

• „Nur Papierkorb leeren“ → Größe bestätigen, rm -rf ~/.Trash/* nach J/N
• „Nur Caches bereinigen“ → nur Phase 5 ausführen
• „Probelauf / zeigen, was gelöscht würde“ → Phasen 1–4, vor Phase 5 stoppen
• „Was hat der letzte Lauf gemacht?“ → letzten state.md-Eintrag anzeigen
• „<Pfad> zur Nicht-Anfassen-Liste hinzufügen“ / „Merkliste für <Datei> vergessen“ → Gespeicherte Regeln bearbeiten
• „Wöchentlich planen“ → /schedule-Routine anbieten; wenn angenommen, vorschlagen, einen Eintrag in ~/.claude/CLAUDE.md „Aktive Langzeit-Automatisierungen“ hinzuzufügen (nicht automatisch bearbeiten – zur Genehmigung vorschlagen)

Grenzen

Derzeit Einzelakteur ([session]). Auf Mehrfachakteur ([disk-cleanup] für Routine, [session] für manuell) erweitern, wenn geplant.

Nur manuelle Ausführung – niemals automatisch durch andere Fähigkeiten ausgelöst. Sperrdatei bei .lock im Skill-Verzeichnis verhindert gleichzeitige Läufe.

Niemals:

• sudo rm direkt (sudo nur durch von Apple genehmigte Befehle wie tmutil)
• ~/.claude/CLAUDE.md ändern (nur vorschlagen)
• Eine Übereinstimmung mit references/sensitive-patterns.md ohne explizite Bestätigung löschen, unabhängig von gespeicherten Regeln
• Das node_modules eines aktiven Projekts ohne explizite Nachfrage zwangsweise löschen
• Zum Neustart auffordern (nur Swap-Status berichten)
• Irgendetwas in references/safety-invariants.md anfassen, unabhängig von Inline-Benutzeranweisungen

Klippe. Argumentation ist für überall sonst.