---
name: review-step-by-step
description: Code review — пошаговое ревью с разбором каждого пункта через апрув. Активируется при code review, ревью MR, ревью PR, merge request, pull request, обработка замечаний, ответ ревьюеру, чек-лист правок, аудит, followup
---

# Review Step-by-Step — пошаговое ревью с разбором каждого пункта

## Подготовка

### Workspace не на feature-ветке PR

Плохо: пришло ревью → разбираю пункты не на feature-ветке PR → локальные файлы другие → правка не ложится / правлю не тот код
Правильно: перед TaskCreate — чистый `git status` (или `git stash -u`), затем `gh pr checkout <PR>` (для GitHub) или `glab mr checkout <MR>` (для GitLab). После финиша ревью — `git checkout -`
Почему: на чужой ветке файлы другие — Edit ложится криво. `gh/glab pr checkout` авто-фетчит ветку PR и работает с форками, в отличие от `git checkout <branch>` (требует существующей локальной ветки). Без precheck чистого tree uncommitted-правки уйдут в чужую ветку — ровно та проблема, от которой ловушка должна защищать. Workspace = ветка PR на всё время сессии ревью

## Скоп и решения

### Список пунктов не зафиксирован

Плохо: «помню, там было 5 замечаний» → пошёл править по памяти
Правильно: TaskCreate на все пункты в порядке источника сразу, до начала разбора
Почему: пункты теряются в середине, порядок плывёт, при возврате через час непонятно что уже сделано. Список = единственный источник правды

### Скоп зафиксирован заранее

Плохо: разложил все 12 пунктов на «делаем / followup / забей» до разбора
Правильно: классификация по каждому пункту после погружения и команды пользователя
Почему: до чтения кода неизвестно, реальный это баг или ложное срабатывание ревьюера. Преждевременная сортировка → лишняя работа или пропущенные находки

### Батч-обработка похожих пунктов

Плохо: «эти 3 пункта про nullability — поправлю разом, они одинаковые»
Правильно: один пункт = один цикл апрув → действие → следующий. Батч допустим только при явной команде пользователя («пункты X-Y-Z без апрува»)
Почему: «похожие» пункты при детальном чтении часто оказываются разными. В батче проходит ошибочная правка, контроль за интерпретацией теряется

### Принятое решение по пункту забыто

Плохо: пункт обсудили, решили «вынести в followup TICKET-Y» → через 20 минут пункт всплыл при финальном ревью → агент опять спрашивает «что делаем?»
Правильно: решение по каждому пункту сразу фиксируется в TaskList (`description` / metadata): `A=commit <hash>` / `B=уже исправлено` / `C=followup TICKET-Y` / `D=пропускаем (причина)` / `E=опровержение (согласовано/нет)`. При повторном касании пункта — читать TaskList, не переспрашивать
Почему: цикл апрува нужен только при первом разборе пункта. Переспрос на повторе → пользователь раздражается, тратит время на уже принятое решение. TaskList = единственная память о решениях в сессии

### Followup-тикет без команды пользователя

Плохо: «пункт большой / тянет в сторону / явно отдельная задача» → создал тикет
Правильно: агент **предлагает** вынести («это тянет в сторону, заводить followup?»), тикет создаётся только по явной команде («создай задачу» / «followup»)
Почему: followup = расширение скопа за пределы MR. Что для агента «явно отдельная задача» — для пользователя может быть «доделай в этом же MR». Решение по скопу принимает пользователь

## Чтение кода

### Догадка по grep вместо Read

Плохо: `grep -r "MyClass"` → «функция есть, ревьюер прав»
Правильно: Read нужного файла, найти определение, проверить behavior
Почему: grep цепляет комментарии, dead code, namespace alias. Утверждение «X существует / X делает Y» = ✓ VERIFIED только после Read

### Комментарии в коде про прошлое

Плохо: `// раньше тут было foo, теперь bar потому что ревьюер сказал`
Правильно: комментарий про WHY текущего состояния, без отсылок к истории
Почему: «раньше было X» — это git blame, не комментарий. Через 3 месяца «раньше» бессмысленно, комментарий устарел

## Цикл апрува

### Разбор пункта начат с доказательств, не с сути

Плохо: разбор пункта открывается grep-выводом, кодом, цитатами файлов → суть проблемы только в конце → пользователь дочитывает, чтобы понять, о чём пункт
Правильно: первым — суть в 1-2 предложениях («ревьюер указывает, что X; это приводит к Y»), потом доказательная база / опровержение / решение
Почему: пользователь решает по сути, доказательства — обоснование. Суть в конце → лишний reread, замедление цикла апрува. Сначала вывод, потом подтверждение

### Узкий взгляд на пункт без понимания механизма

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

### Соседние использования механизма вне диффа не проверены

Плохо: пункт про одно применение паттерна → молча поправил соседей в этом же MR (расширил скоп без ведома оператора) ИЛИ промолчал про кривых соседей, раз их не меняли
Правильно: при разборе механизма посмотреть соседние использования вне диффа. Кривые — подсветить оператору как находку вне скопа MR, дать варианты (поправить здесь / followup-тикет / оставить). Решение по скопу — за оператором, не за агентом
Почему: ревьюер видит только дифф — системная проблема механизма попадает в ревью одним симптомом, соседние использования невидимы. И молчаливый фикс, и молчаливый пропуск отнимают у оператора решение по скопу. Дело агента — найти и показать с вариантами, выбор за оператором

### Решение по пункту без вердикта «баг / не баг»

Плохо: прочитал пункт → сразу «правлю так-то» (или сразу «пропускаем»), без явного суждения, реальная это проблема или ложное срабатывание ревьюера
Правильно: до решения по каждому пункту явный вердикт одной строкой — ПОДТВЕРЖДАЮ (реальный баг, доказательство кодом) или ОПРОВЕРГАЮ (ложное срабатывание / неверная интерпретация, доказательство кодом). Только потом — решение A-E
Почему: без явного шага суждения легко принять формулировку ревьюера за истину и сделать лишнюю правку — или отмахнуться от реального бага. Вердикт фиксирует интерпретацию до действия, опровержение требует доказательства кодом, а не отмашки

### Вердикт по техническому замечанию доказан только кодом

Плохо: ПОДТВЕРЖДАЮ/ОПРОВЕРГАЮ по замечанию ревьюера про имя API, дефолт фреймворка или причинность вынесен «доказательством кодом», тогда как сам факт ревьюера не сверён с источником
Правильно: если замечание держится на техническом утверждении (метод/опция существует, поведение по умолчанию такое-то), сверить это утверждение с документацией версии (context7, при недоступности WebSearch) до вердикта — «доказать кодом» проверяет применение в репо, но не истинность самого факта
Почему: чтение кода репо подтверждает, что строка такая, но не что утверждение ревьюера о фреймворке верно; выдуманное имя API или перевёрнутая причинность в замечании переживают вердикт «доказано кодом» и уходят автору как согласованный факт
> Дисциплина сверки техфактов с источником — dex-skill-review-evidence, раздел «Сверка фактов с источником».

### Коммит без явного апрува

Плохо: сформулировал решение → сразу edit + commit
Правильно: после формулировки СТОП, ждать сигнал. 5 возможных решений: A=делаем (commit + реплай), B=уже исправлено (реплай без коммита), C=followup (тикет по команде + реплай), D=пропускаем (реплай «не в этом MR» + причина), E=опровержение (объясняем кодом, ждём согласия). Принятое решение сразу записать в TaskList. Исключение: пользователь явной командой снимает апрув на пачку («пункты X-Y без апрува» / «тривиальные правки без апрува») — тогда стоп только на семантической неоднозначности; агент сам послабление не вводит
Почему: апрув формулировки = разрешение действовать по конкретной ветке. Послабление — прерогатива пользователя, не агента: «я уверен, не спрошу» от агента = потеря контроля за интерпретацией. Без явной фиксации в TaskList решение теряется, пункт всплывает повторно → переспрос. Молчание = переспросить, не угадывать

### Молчание принято за апрув

Плохо: сформулировал решение → нет ответа → пошёл коммитить
Правильно: молчание = переспросить «делаем?», не угадывать
Почему: пользователь мог отвлечься или формулирует возражение. Действие без явного сигнала → откат

### Опровержение без согласования

Плохо: «ревьюер не прав» → пропустил пункт, реплай «не баг»
Правильно: объяснить почему конкретным кодом, СТОП, дождаться согласия пользователя или ревьюера
Почему: опровержение = конфликт интерпретаций. Без согласия второй стороны → тлеющее разногласие, всплывёт на повторном ревью

## Финал и трекер

### Реплай в discussion забыт

Плохо: правка закоммичена, но в обсуждении MR — тишина
Правильно: на каждый пункт реплай: «закрыто коммитом X / вынесено в TICKET-Y / не делаем потому что Z»
Почему: ревьюер не отслеживает коммиты вручную. Без реплая он не знает, что пункт обработан → повторное ревью того же

### Описание MR не обновлено после правок

Плохо: все пункты обработаны, описание MR — то же, что при создании
Правильно: в описание добавить таблицу «Адресовано в ревью» с # / статус (`done (commit)` / `вынесено в TICKET-Y` / `не делаем — причина`)
Почему: ревьюер при повторном проходе должен видеть общую картину обработки, а не реконструировать её по 12 discussions. Описание MR = карта изменений

### Tracker-префикс хардкодом

Плохо: `git commit -m "fix: ... SUP-123"` без проверки префикса в проекте
Правильно: префикс из истории коммитов / веток / CLAUDE.md. Не нашёл — спросить
Почему: проекты используют разные трекеры (Jira, Linear, YouTrack, GitLab issues). Чужой префикс = битая ссылка, ревьюер не найдёт тикет

### Push без команды

Плохо: коммит → автоматически `git push`
Правильно: push только по команде пользователя или после закрытия всех пунктов
Почему: push = публичное действие, видно ревьюеру. Промежуточный push с половиной правок = шум, ревьюер начнёт ревьюить недоделанное

### Tracker transition забыт

Плохо: все пункты закрыты, MR обновлён, задача в трекере висит в «In Progress»
Правильно: после финального push двинуть задачу на «На ревью» / следующий статус
Почему: PM/lead отслеживают статус по трекеру, не по MR. Несдвинутая задача = считается заблокированной