cleaner — уборщик мусорных файлов

Когда применять

• Явная просьба почистить проект.
• Всегда, когда ты собрался удалить мусорный файл — даже один, даже «по-быстрому»: git status показал лишнее, уборка перед коммитом, пустой файл в корне, битое имя. Скилл поднимается ДО удаления, а не после (см. правило 0).

Скилл сканирует проект, группирует находки, спрашивает подтверждение по каждой группе и запоминает решения для будущих авточисток.

Правила (must follow)

0. Любое удаление мусора — только через этот скилл. Никаких rm/Remove-Item мимо него — даже для одного файла, даже когда «очевидно». Ручное удаление обходит подтверждение групп, правила cleaner_rules.json и защиту из правил 6-7 (секреты, значимые пустышки, битые имена), а на битых именах ещё и молча блокируется классификатором. Поднимать скилл ДО первого rm — типовой промах: увидел мусор в git status перед коммитом и удалил руками, не открыв скилл.
1. Ничего не удалять без подтверждения (кроме групп с сохранённым правилом auto: true).
2. Сначала скан, потом план, потом действие. Показать группы → дождаться ответа по каждой → только потом удалять.
3. Правила хранить в data/cleaner_rules.json этого скилла. Формат: {"<project_name>": {"<group_key>": {"auto": true|false, "since": "<date>"}}}
4. При auto:true — удалять без вопроса, но показывать сводку что удалено.
5. Группы, для которых нет правила — всегда спрашивать.
6. Не трогать: .git/, .obsidian/, .env, credentials.*, *.key, *.pem, secrets/, файлы в .gitignore кроме явно указанных категорий.
7. Файлы с не-ASCII/битыми именами — отдельная группа broken_names, всегда ручное подтверждение (auto-правило не применяется — имена разные). Пустые значимые конфиги/код (empty_significant) — тоже вне auto.
8. Удаление — только через движок scripts/cleaner.py (Python, не shell). Почему: auto-mode классификатор блокирует shell-команды с битыми/не-ASCII именами в аргументах (Remove-Item/rm с кракозябрами → denied). Python удаляет по абсолютному пути через os.remove/shutil.rmtree — имена файлов не попадают в argv, классификатор пропускает вызов. Не удалять файлы напрямую через Bash/PowerShell tool.

Движок scripts/cleaner.py

Все скан/удаление идут через него. Всегда печатает JSON в stdout. На Windows перед вызовом ставить PYTHONIOENCODING=utf-8 (иначе печать битых имён падает на cp1251-консоли). Интерпретатор — общее окружение скиллов $env:SKILLS_PY ($SKILLS_RUNTIME/.venv), а не venv проекта: движку хватает stdlib, но скилл подключён к разным проектам, и проектного venv может не быть.

# Скан → JSON-план (группы, счётчики, имена, размеры)
$env:PYTHONIOENCODING='utf-8'; & $env:SKILLS_PY $SKILLS_HOME/skills\cleaner\scripts\cleaner.py <project_dir> --scan

# Удалить подтверждённые группы (одна или несколько)
$env:PYTHONIOENCODING='utf-8'; & $env:SKILLS_PY $SKILLS_HOME/skills\cleaner\scripts\cleaner.py <project_dir> --delete empty_files broken_names

# Удалить ВЫБОРОЧНО внутри группы (--items: имя или полный путь)
$env:PYTHONIOENCODING='utf-8'; & $env:SKILLS_PY $SKILLS_HOME/skills\cleaner\scripts\cleaner.py <project_dir> --delete empty_significant --items "a.yml" "b.yml"

# Авто-режим: применить сохранённые auto-правила, остальное вернуть в план
$env:PYTHONIOENCODING='utf-8'; & $env:SKILLS_PY $SKILLS_HOME/skills\cleaner\scripts\cleaner.py <project_dir> --auto

Ключ правил (--rules) по умолчанию — ../data/cleaner_rules.json рядом со скриптом.

Группы (классифицирует движок)

heavy_envs — рабочие окружения, а не мусор. Движок держит их отдельной группой и никогда не включает в build_artifacts: до 2026-07-16 venv классифицировались как build_artifacts, и --delete build_artifacts сносил боевые окружения (в корп-проекте это ~3 ГБ: три venv из CLAUDE.md + node_modules), а защита держалась лишь на внимательности вызывающего. Группу показывать в плане как справку и никогда не предлагать к удалению без явного запроса пользователя — их снос ломает проект и стоит часы переустановки.

.playwright-mcp/ — не сплошной мусор. Рядом со снимками там живут chrome-profile (cookies и авторизации — их снос означает переавторизацию везде) и сохранённые пользователем страницы/PDF. Движок с 2026-07-20 спускается внутрь и берёт только файлы по шаблону снимка, профили пруним, остальное не трогает. Не предлагать удаление MCP-каталога целиком.

Пустышки движок чистит только в корне — 0-байтные файлы глубже (в logs/, store/, data/) обычно runtime-данные фич, не мусор скилла.

Грабли: пустой файл ≠ мусор. empty_significant — это группа «посмотри глазами», а не «удали». Проверяй КАЖДЫЙ файл до удаления: 0 байт бывает у сломанного конфига, который надо восстановить, а не снести. Реальные случаи корп-проекте (16.07.2026):

• .claude/rules/auto-invoke.md — пуст, но на него ссылается CLAUDE.md («Таблица триггеров»). Удалить = закрепить поломку вместо починки. Правильный ответ — сообщить пользователю.
• src/zrepamak/logs/query_log.sql — пуст, лежит в logs/ робота: может создаваться кодом при запуске. Цена ошибки выше выгоды от 0 Б. Ищи, кто ссылается на файл (grep по имени), прежде чем предлагать удаление.

Процедура

1. Скан: & $env:SKILLS_PY <cleaner>\scripts\cleaner.py <проект> --scan → распарсить JSON-план.
2. План: показать группы (счётчик + имена + размер). Смешанные группы разбирать поштучно, а не целиком: в empty_significant/broken_names рядом с мусором лежат файлы, которые трогать нельзя (см. грабли ниже) — для них --delete <группа> --items <имена>, остальные элементы уйдут в skipped. Для каждой группы спросить Удалить группу X? [y/n/auto]:
   • y — удалить сейчас;
   • n — пропустить;
   • auto — удалить сейчас И запомнить правило (кроме broken_names и empty_significant — им auto недоступен).
3. Удаление: & $env:SKILLS_PY <cleaner>\scripts\cleaner.py <проект> --delete <группы> для подтверждённых y/auto. Показать сводку из JSON (что удалено, байт).
4. Сохранение правил: обновить data/cleaner_rules.json для групп с auto. Формат: {"<project>": {"<group>": {"auto": true, "since": "<date>"}}}. Ключ проекта = имя каталога. broken_names/empty_significant в auto не пишем (движок их всё равно отфильтрует).

Данные

Перед работой: git -C $SKILLS_HOME pull. При активации допиши строку <дата> cleaner <проект> в data/usage.log. Правила: data/cleaner_rules.json — git add + commit + push после изменений.

Обратная связь

Если пользователь недоволен работой скилла — немедленно:

1. Прочитай последние ~20 строк CHANGELOG.md — нет ли уже такой жалобы
2. Спроси: что ожидал, что получил, что поправить
3. Исправь SKILL.md (только инструкция) и допиши правку в конец CHANGELOG.md: `

   YYYY-MM-DD

   • Запрошено: <что просил пользователь>
   • Изменено: <что конкретно поправлено в SKILL.md> `
4. Commit + push обоих файлов в master

CHANGELOG.md читается только с конца (последние записи) — не грузи весь в контекст.