# Change Review

> Глубокий разбор ОДНОГО изменения — диффа, файла или пары связанных правок — с вердиктом APPROVE / APPROVE WITH COMMENTS / REQUEST CHANGES и шкалой критичности. Два режима: self — силами Claude (корректность, безопасность, надёжность на проде, производительность, границы слоёв); second-opinion — тот же код смотрит ДРУГАЯ модель через внешний CLI (галлюцинации API, edge cases, over-engineering). Вызывается ЯВНО. Используй когда пользователь говорит «код ревью, если не было», «сделай ревью», «посмотри мой код», «есть ли тут баги», «безопасен ли код», «второе мнение», «оцени два подхода и выбери лучший». Быстрый построчный гейт по диффу — /code-review; весь бэкенд с оценкой — python-project-audit.

- Skill: `goldenprofile/change-review` (Agent Skill, multi-file: 6 files)
- Install (CLI): `npx skillmds@latest add goldenprofile/change-review`
- Raw SKILL.md: https://api.skillmd.com/api/skills/goldenprofile/change-review/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security
- Author: goldenprofile (https://skillmd.com/u/goldenprofile)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/goldenprofile/change-review

---


# Change Review

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

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

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

| Режим | Когда | Кто ревьюит |
|---|---|---|
| **self** | обычный случай: «посмотри мой код», «есть ли тут баги» | Claude, по [references/self-review.md](references/self-review.md) |
| **second-opinion** | код писал Claude и нужен независимый взгляд; «работает, но странно»; перед деплоем крупного изменения | другая модель, по [references/second-opinion.md](references/second-opinion.md) |

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