Simplify Code

Параллельная очистка недавних изменений кода тремя агентами.

Метаданные навыка

Источник	Встроенный (устанавливается по умолчанию)
Путь	skills/software-development/simplify-code
Версия	1.0.0
Автор	VibeOS (вдохновлено Claude Code /simplify)
Лицензия	MIT
Платформы	linux, macos, windows
Теги	code-review, cleanup, refactor, delegation, subagent, parallel, simplify
Связанные навыки	requesting-code-review, test-driven-development, plan

Справочник: полный SKILL.md

к сведению

Ниже приведено полное определение навыка, которое VibeOS загружает при его активации. Это те инструкции, которые видит агент, когда навык активен.

Simplify Code — Параллельный обзор и очистка

Просмотрите ваши недавние изменения кода с помощью трёх сфокусированных рецензентов, работающих параллельно, объедините их результаты и примените исправления, которые стоит применить.

Основной принцип: Три узких рецензента лучше одного широкого. Каждый из них глубоко ищет в кодовой базе проблемы одного класса — повторное использование, качество, эффективность — не разбавляя своё внимание на все три сразу. Они работают одновременно, поэтому вы платите за задержку одного обзора, а не трёх.

Когда использовать

Запускайте этот навык, когда пользователь говорит что-то из:

• «simplify» / «simplify my changes» / «simplify these changes»
• «review my code» / «review my recent changes» / «clean up my changes»
• «/simplify» (если они перенесли привычку из Claude Code)

Необязательные модификаторы, которые пользователь может добавить — учитывайте их:

• Фокус: «simplify focus on efficiency» → запустить только рецензента эффективности (или взвесить агрегацию в его пользу). Распознаваемые фокусы: reuse, quality, efficiency.
• Пробный прогон: «simplify but don't change anything» / «just report» → запустить трёх рецензентов, представить результаты, НИЧЕГО не применять. Спрашивать перед применением.
• Область: «simplify the last commit» / «simplify staged» / «simplify src/foo.py» → соответствующим образом сузить источник diff'а (см. Фазу 1).

НЕ запускайте это автоматически после каждого редактирования. Это стоит токенов трёх сабагентов — вызывайте его только когда пользователь явно просит.

Процесс

Фаза 1 — Определение изменений

Захватите diff для обзора. Выберите источник в зависимости от того, что запросил пользователь, в следующем порядке по умолчанию:

# 1. По умолчанию: неиндексированные изменения рабочего дерева (отслеживаемые файлы)
git diff

# 2. Если это пусто, включите проиндексированные изменения
git diff HEAD

# 3. Варианты с областью, которые может запросить пользователь:
git diff --staged                 # «проиндексированные изменения»
git diff HEAD~1                    # «последний коммит»
git diff main...HEAD              # «эта ветка» / «мой PR»
git diff -- src/foo.py            # конкретный(е) файл(ы)

Если git diff и git diff HEAD пусты, и нет git-репозитория или изменений, вернитесь к файлам, которые пользователь явно назвал или которые были недавно созданы/отредактированы в этом сеансе. Если вы действительно не можете найти никакого изменённого кода, сообщите об этом и остановитесь — упрощать нечего.

Захватите полный текст diff'а. Отметьте его размер: если он очень большой (скажем, >2000 изменённых строк), предупредите пользователя, что три сабагента, каждый из которых несёт полный diff, будут токено-затратными, и предложите сузить область (по каталогам, по коммитам) перед продолжением.

Фаза 2 — Запуск трёх рецензентов параллельно

Используйте пакетный режим delegate_task — передайте все три задачи в одном массиве tasks, чтобы они выполнялись одновременно. Три — правильное количество для этого шаблона; оно вполне укладывается в бюджет delegation.max_concurrent_children в любой стандартной установке.

Дайте каждому рецензенту полный diff (не фрагменты — проблемы, затрагивающие несколько файлов, прячутся в пробелах), а также абсолютный путь к репозиторию, чтобы они могли искать в более широкой кодовой базе. Каждый рецензент получает наборы инструментов terminal, file и search (чтобы они могли использовать git, read_file и search_files/grep).

Скажите каждому рецензенту:

• Искать в существующей кодовой базе доказательства (не делать выводы только из diff'а).
• Применять забор Честертона: прежде чем помечать что-то для удаления, выполните git blame для этой строки, чтобы понять, почему она существует. Если вы не можете определить первоначальную цель, пометьте как confidence: low — не гадайте.
• Представлять результаты в виде структурированного вывода с указанием уверенности и риска:

  file:line → проблема → предлагаемое исправление | confidence: high/medium/low | risk: SAFE/CAREFUL/RISKY

  • SAFE = доказано, что не влияет на поведение (неиспользуемые импорты, закомментированный код, транзитные обёртки). Применять автоматически.
  • CAREFUL = улучшает без изменения семантики (переименование локальной переменной, упрощение вложенного тернарного оператора, выделение вспомогательной функции). Применять с проверкой тестами.
  • RISKY = может изменить поведение или нарушить публичные контракты (реструктуризация N+1, переименование публичного API, изменение жизненного цикла памяти). Помечать для проверки человеком — НЕ применять автоматически.
• Пропускать придирки и изменения только в стиле. Отмечать только то, что существенно улучшает код.

Передайте эти три цели (исключите любую, которую исключает фокус пользователя):

Рецензент 1 — Повторное использование кода

Проверьте этот diff на наличие кода, который дублирует функциональность, уже существующую в кодовой базе. Ищите в служебных модулях, общих помощниках и соседних файлах (используйте search_files / grep) существующие функции, константы или шаблоны, которые новый код мог бы вызвать вместо повторной реализации. Отмечайте: новые функции, дублирующие существующие; логику, написанную вручную, которую уже выполняет существующая утилита (ручные манипуляции со строками/путями, пользовательские проверки окружения, ad-hoc защитники типов, повторно реализованный парсинг). Для каждого укажите, какой существующий элемент использовать и где он находится.

Рецензент 2 — Качество кода

Проверьте этот diff на проблемы с качеством. Ищите: избыточное состояние (значения, которые дублируют или могут быть получены из существующего состояния; кеши, которые не нужны); разрастание параметров (новые параметры, добавленные туда, где функция должна была быть реструктурирована); копирование-с-вариациями (почти дублирующиеся блоки, которые должны использовать абстракцию); нарушение инкапсуляции (раскрытие внутренностей, нарушение существующей границы инкапсуляции); строково-типизированный код (сырые строки там, где уже существует константа/перечисление/реестр — проверьте канонические реестры, прежде чем отмечать); шаблоны «AI-сгенерированной ерунды» (лишние комментарии, повторяющие очевидный код, например // increment counter над count++; ненужные защитные проверки на null для уже проверенных входных данных; приведение as any, которое обходит систему типов; шаблоны, не соответствующие остальной части файла). Для каждого дайте конкретный рефакторинг.

Рецензент 3 — Эффективность

Проверьте этот diff на проблемы с эффективностью. Ищите: ненужную работу (избыточные вычисления, повторные чтения файлов, дублирующиеся вызовы API, шаблоны доступа N+1); упущенную параллельность (независимые операции, выполняемые последовательно); раздувание горячего пути (тяжёлая/блокирующая работа при запуске или на каждом запросе); анти-шаблоны TOCTOU (предварительные проверки существования перед операцией вместо выполнения операции и обработки ошибки); проблемы с памятью (неограниченный рост, отсутствие очистки, утечки слушателей/обработчиков); чрезмерно широкое чтение (загрузка целых файлов, когда достаточно части); тихие сбои (пустые блоки catch, игнорируемые возвраты ошибок, except: pass, .catch(() => {}) без обработки, пробелы в распространении ошибок — они скрывают баги и должны как минимум логировать перед проглатыванием). Для каждого дайте конкретное исправление и объясните, почему это быстрее или безопаснее.

Фаза 3 — Агрегация и применение

Дождитесь возврата всех трёх (пакетный режим возвращает их вместе).

1. Объедините результаты в один список, удаляя дубликаты там, где рецензенты пересекаются.
2. Отбросьте ложные срабатывания — у вас есть наибольший контекст; вам не нужно спорить с рецензентом, просто молча отбросьте слабые или неверные предложения.
3. Разрешите конфликты. Рецензенты могут не соглашаться (Рецензент 1: «используйте существующую утилиту X»; Рецензент 3: «X медленный, встройте его»). Порядок разрешения по умолчанию: корректность > указанный фокус пользователя > читаемость/повторное использование > микро-производительность. Не применяйте «исправление» производительности, которое вредит ясности, если только путь действительно не является горячим. Когда два предложения взаимоисключающие и оба обоснованы, выберите то, которое затрагивает меньше кода, и отметьте альтернативу.
4. Применяйте в порядке уровней риска:
   • Сначала SAFE (автоматическое применение): неиспользуемые импорты, закомментированный код, транзитные обёртки, избыточные утверждения типов. Запустите тесты после.
   • Затем CAREFUL (применение с проверкой, по одному файлу за раз): переименование локальных переменных, упрощение тернарных операторов, выделение вспомогательных функций, консолидация дубликатов. Запускайте тесты после каждого файла. Откатывайте любые, которые ломают.
   • Последними RISKY (пометить для проверки — НЕ применять автоматически): реструктуризация N+1, изменения публичного API, исправления параллельности, изменения обработки ошибок. Представляйте каждое с описанием риска и статусом тестового покрытия. Если пользователь выбрал пробный прогон, представьте все три уровня и ничего не применяйте.
5. Проверьте, что ничего не сломали: запустите целевые тесты проекта для затронутых файлов (не весь набор) и повторно запустите любой линтер/проверку типов, которые использует репозиторий. Если исправление ломает тест, откатите это одно исправление и сообщите об этом.
6. Подведите итог того, что вы изменили: краткий список применённых исправлений, сгруппированных по категории рецензента и уровню риска, а также любые результаты, которые вы намеренно пропустили, и почему.

Подводные камни

• Не расширяйте веер более чем до ~3. Больше рецензентов означает больше затрат и больше конфликтующих предложений для согласования, а не лучшее покрытие. Три категории покрывают пространство.
• Давайте ВЕСЬ diff каждому рецензенту. Разделение diff'а между рецензентами разрушает замысел — дублирование в разных файлах и N+1 проявляются только при полной картине.
• Рецензенты ищут, а не гадают. Результат о повторном использовании без указания на существующую утилиту («вероятно, для этого есть помощник») — это шум. Требуйте доказательств в виде file:line; отбрасывайте результаты, в которых их нет.
• Применить ≠ переписать. Это очистка недавних изменений пользователя, а не разрешение на рефакторинг всего модуля. Ограничивайте изменения тем, что затронул diff, плюс минимальные окружающие изменения, необходимые для исправления.
• Уважайте соглашения проекта. Если в репозитории есть AGENTS.md / CLAUDE.md / VIBEOS.md или конфигурация линтера, включите эти правила в подсказки рецензентам, чтобы предложения соответствовали внутреннему стилю, а не боролись с ним.
• Большие diff'ы раздувают контекст. Если diff огромен, сузьте его область перед делегированием — три сабагента, каждый с diff'ом в 5000 строк, дорого и может привести к усечению.
• Чрезмерное доверие инструментам поиска мёртвого кода. knip, ts-prune и depcheck помечают экспорты, которые ИСПОЛЬЗУЮТСЯ динамически (импорты на основе строк, рефлексия). Всегда ищите имя символа с помощью grep перед удалением — чистый отчёт инструмента не является доказательством.
• Переименование без проверки публичных контрактов. Имена экспортов, пути API-маршрутов, имена столбцов БД и ключи конфигурации — это контракты; даже если имя плохое, переименование ломает потребителей. Помечайте изменения публичных контрактов как RISKY; никогда не переименовывайте их автоматически.
• Удаление «ненужной» обработки ошибок. Пустой блок catch или игнорируемая ошибка могут быть намеренными — ошибка ожидаема и безвредна в данном контексте. Отметьте это, не удаляйте; пусть человек решает.

Связанное

Если в вашей установке есть навык subagent-driven-development (необязательный), он охватывает дополняющий случай: параллельный обзор во время реализации, для каждой задачи. Этот навык — самостоятельный проход очистки после факта. Используйте requesting-code-review для предкоммитного шлюза безопасности/качества.