# Scope Review

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

- Skill: `tony-adamson/scope-review` (Agent Skill)
- Install (CLI): `npx skillmds@latest add tony-adamson/scope-review`
- Raw SKILL.md: https://api.skillmd.com/api/skills/tony-adamson/scope-review/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: tony-adamson (https://skillmd.com/u/tony-adamson)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/tony-adamson/scope-review

---


# Scope Review → находки об избыточности

`/code-review` проверяет, что код **делает задуманное**. `/ops-review` — чего в коде **не хватает**. Этот навык проверяет третье: что в diff **не должно существовать**. Класс дефекта — избыточный scope: добавления без вынуждающего требования, чужеродные паттерны, прослойки, неверное место данных. Это главный источник CHANGES_REQUESTED на человеческом ревью и главный систематический перекос LLM-генерации.

## Жёсткие границы

Запрещено:

- править код, тесты, конфиги, схемы, зависимости — только находки;
- создавать файлы-артефакты — отчёт идёт в чат;
- расширяться в аудит всего репозитория: рамка — diff и его непосредственный контекст;
- признавать пункт проверенным без доказательства `file:line`;
- превращать вкусовые предпочтения в BLOCKING: находка обязана указывать нарушенное правило из списка ниже.

## Контракт запуска

1. Определить рамку ревью:
   - явный git ref/range или путь из аргументов;
   - иначе — рабочее дерево + diff ветки против merge-base с интеграционной веткой (не предполагать, что это `main`);
   - рамка пуста или неоднозначна — спросить, статус `SCOPE_REVIEW_BLOCKED`.
2. Если diff идентичен уже проверенному в этой сессии (сверить `git diff --stat`) — вернуть `SCOPE_REVIEW_NO_CHANGE` одной строкой и завершить. Это делает навык дешёвым при повторных прогонах и в `/loop`.
3. Прочитать постановку задачи из контекста сессии (scope-контракт, issue, сообщение пользователя). Постановки нет — проверки 1 и 8 выполнять против минимальной интерпретации diff и пометить это в отчёте.
4. Если в проекте существует `.claude/reviewer-profile.md` — прочитать и применить как дополнительные правила поверх базовых. Отсутствие файла — норма, не находка.

## Проверки

1. **Обоснованность каждого добавления.** Для каждого нового объекта — файл, route/endpoint, таблица/колонка/связь, env-переменная, аргумент функции, класс, зависимость, config-ключ — назвать конкретное текущее требование, которое его вынуждает. «Пригодится», «для тестируемости», «так принято» — не обоснование. Нет требования — BLOCKING.
2. **Мимикрия под локальные паттерны.** У нового кода есть аналог в репозитории (конфиг, таска, handler, схема)? Сравнить структуру, именование, обработку ошибок. Отклонение от локального паттерна без вынуждающей причины — находка со ссылкой на эталонный файл.
3. **Прослойки и косвенность.** Функции с единственным call site, `Callable`/callback-аргументы, одноразовые обёртки и private-helpers, фасады — кандидаты на инлайн или прямой вызов. Абстракция оправдана только вторым реальным call site в этом же diff или существующем коде.
4. **Модель исполнения.** async-код в синхронном рантайме (sync Celery, скрипт) и наоборот; потоки/пулы там, где рантайм уже даёт конкурентность.
5. **Место данных.** Глобальная конфигурация — config-модуль; секреты и окружение — env; настройки конкретной сущности — хранилище этой сущности (БД). Константа в env, сущностный атрибут в config — находка.
6. **Дублирование.** Повторённые условия, строки/сообщения, команды, уже заданные в другом слое (Compose/CI/Makefile), пересчёт уже вычисленного.
7. **Гигиена diff.** `git diff --stat`: каждый затронутый файл обоснован задачей; файлы вне рамки (DI, схемы, чужие конфиги) — BLOCKING. Пустые директории, осиротевшие файлы, удалённые строки, нужные существующему коду.
8. **Контрактные литералы.** Каждый новый статус, enum-значение, route, namespace, имя поля внешнего API — проверить существование в кодовой базе или документации из контекста. Не нашёл — WARN с пометкой `UNVERIFIED`, не выдумывать подтверждение.
9. **Тесты доказывают, а не имитируют.** Тавтологический тест — ожидаемое значение вычислено тем же способом, что и в коде (`assert add(a, b) == a + b`, снапшот, снятый с самого кода, константа против самой себя) — BLOCKING: ожидание должно приходить из независимого источника (известный литерал, пример из требования). Тест, завязанный на внутренности (моки внутренних коллабораторов, проверка через побочный канал вроде прямого запроса в БД вместо интерфейса), и тест на шве, не названном в scope-контракте (`Проверки: шов = …`), — WARN со ссылкой на согласованный шов.

## Отчёт

- Вердикт первой строкой: `SCOPE_REVIEW_OK` / `SCOPE_REVIEW_FINDINGS <n>` / `SCOPE_REVIEW_NO_CHANGE` / `SCOPE_REVIEW_BLOCKED`.
- Находки по убыванию тяжести: `BLOCKING` (необоснованное добавление, файл вне рамки, несуществующий контракт) / `WARN` (прослойка, отклонение от паттерна, место данных, дублирование) / `INFO`.
- Формат находки: `file:line` — правило (№ из списка) — суть одним предложением — минимальное направление исправления (что убрать/заинлайнить/куда перенести), без патча.
- Пройденные проверки перечислить одной строкой каждую, с доказательством (какие объекты рассмотрены).
- Не более 15 находок; остальное свернуть в одну строку со счётчиком.