Change Review

Change Review

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

Навык вызывается явно. Не запускай его после каждой правки: это дублирует /code-review и жжёт контекст.

Шаг 0. Выбери режим

Режим second-opinion требует внешнего CLI, который отправит промт модели другого семейства и напечатает ответ (llm, aider --message, CLI провайдера, hermes — подойдёт любой; подробности в справочнике). Ничего подходящего не настроено — скажи об этом прямо и предложи self, не пытайся эмулировать «другую модель» собой: ассистент, проверяющий сам себя, — это режим self, а не второе мнение.

Обязательный шаг: контекст проекта

До любого вывода прочитай CLAUDE.md полностью, релевантные секции ARCHITECTURE.md, при наличии AGENTS.md. Ищи запреты («никогда не делай X»), соглашения по коду, предупреждения о race conditions и тяжёлых операциях.

Эти документы каноничны: рекомендация, противоречащая им, — ошибочна. Если их нет, отметь это в начале отчёта: рекомендации могут не учитывать неявные соглашения проекта.

Вердикт и шкала

Итог всегда один из трёх: APPROVE / APPROVE WITH COMMENTS / REQUEST CHANGES.

• CRITICAL — уязвимость, риск потери данных, ломающий баг. Правится до мержа.
• WARNING — производительность, надёжность, поддерживаемость. Следует исправить.
• SUGGESTION — улучшение, необязательное к исполнению.
• GOOD — удачное решение, которое стоит отметить явно.

Каждая находка: где (file:line), чем опасна, что сделать. Без «возможно стоит подумать» — либо есть проблема и она называется, либо находки нет.

Границы

• Область — принесённое изменение и его непосредственный контекст. Не переписывай приложение, если не просили.
• Не придирайся к форматированию, если в проекте есть автоформаттер.
• Признавай, что код хорош, когда он хорош. Выдуманная проблема хуже пропущенной: она обесценивает остальной отчёт.
• Предполагай production-окружение: к безопасности и надёжности строг.
• Не предлагай удалить «временный» alias или старый путь, не проверив через Grep, используется ли он ещё.
• При разборе нескольких коммитов не приписывай текущему проблемы из старых — сверяйся с git log / git blame по изменённым строкам.

Связь с библиотекой навыков

• /code-review (офиц.) — быстрый построчный гейт по диффу, умеет --fix и --comment. Этот навык — про решения, а не про строки.
• python-project-audit — весь бэкенд с балльной оценкой готовности.
• django-audit — Django-специфика по линзам (ORM/N+1, Celery, settings).
• codebase-recon — понять, как устроено, без вынесения приговора.
• harness-engineering — если ревью вскрыло системную проблему, чинить нужно DoD и канон-документы, а не отдельный дифф.
• agent-workflow (режим prompt) — если запрос на ревью размыт, сформулируй до.

Справочники

• references/self-review.md — режим self: на что смотреть по приоритету, формат отчёта, тон.
• references/second-opinion.md — режим second-opinion: требования к CLI, выбор модели, режимы входа (дифф, файлы, архитектура), дробление большого входа.
• references/lenses.md — пять линз (Скептик, Безопасность, Надёжность, Производительность, Поддерживаемость): когда какая полезна и как комбинировать.
• references/audit-prompts.md — готовые промты для модели-аудитора.
• references/output-format.md — формат представления результатов второго мнения.