requesting-code-review - Запрос независимой проверки кода

Когда звать

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

Проверяющему нужен результат работы

Requesting-code-review описывает, как отправить код отдельному агенту на проверку до слияния. Главное отличие от простой просьбы «посмотри мою работу» состоит в подготовке контекста. Проверяющий получает краткое описание изменения, требования и границы коммитов. Историю всей текущей сессии передавать не предлагается: в ней слишком много рассуждений автора, не относящихся к оценке готового результата.

В основном файле обязательными моментами названы завершение каждой задачи при работе через отдельных исполнителей, окончание крупной функции и подготовка слияния в main. Дополнительная проверка полезна, когда работа зашла в тупик, предстоит переработка или исправлен сложный дефект. Это рекомендации о времени обращения, а не заявление о том, что любой проект уже располагает нужным инструментом делегирования.

Как задать границы обзора

Сначала определяются начальный и конечный коммиты. В простом случае автор показывает предыдущий и текущий HEAD, а для целой ветки допускает общую точку с основной веткой. Важно выбрать диапазон, который действительно содержит передаваемую работу. Последний коммит не равен всей задаче, если она заняла несколько сохранений. Неправильная граница оставит часть реализации вне поля зрения проверяющего.

Для запроса используется отдельный шаблон code-reviewer.md из папки скилла. Основной файл перечисляет его поля: DESCRIPTION для сделанного, PLAN_OR_REQUIREMENTS для ожидаемого, BASE_SHA и HEAD_SHA для диапазона. Агенту общего назначения передают заполненный запрос. Мы проверили наличие ссылки и описание процедуры в SKILL.md; поведенческий запуск проверяющего при подготовке карточки не выполнялся.

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

Что происходит после замечаний

Автор разделяет находки по тяжести. Критические исправляются немедленно, важные до продолжения, мелкие можно записать для последующей работы. Если проверяющий ошибся, допускается аргументированное возражение с кодом и тестами. Спор ради защиты собственного решения и игнорирование обоснованной проблемы в источнике относятся к плохому поведению.

Получение замечаний и их обработка здесь не смешаны: отдельная карточка receiving-code-review посвящена проверке уже пришедших советов. Requesting-code-review организует именно запрос. Его подключение не создаёт рецензию автоматически, не отправляет публикацию в GitHub и не означает одобрения кода человеком. Проверенный паспорт фиксирует файл из Superpowers 7.0.1 и MIT одного коммита; качество будущего заключения зависит от переданных требований, доступного проверяющего и последующей проверки исправлений.