Промпт для ревью кода: как получить полезные замечания

1. Зафиксируйте объект ревью

Укажите commit range, PR или patch и запретите смешивать замечания к несвязанному грязному дереву. Если ветка меняется во время анализа, сохраните точный SHA.

Ревью рабочего дерева без границы легко приписывает чужое изменение текущей задаче.

2. Объясните назначение и контракты

Кратко опишите пользовательский результат, авторитетные состояния и запретные переходы. Для оплаты это может быть правило: только confirmed callback создаёт право выдачи.

Код нельзя оценить только по синтаксису, если неизвестно, какой бизнес-инвариант он защищает.

3. Задайте порядок рисков

Сначала безопасность и потеря данных, затем корректность, гонки, совместимость и производительность, после этого поддерживаемость. Стилевые предпочтения не должны скрывать дефект уровня оплаты.

Для SQL отдельно попросите проверить параметры, row locks, stale guard и N+1. Для UI - XSS, auth guard, empty/error states и mobile.

4. Требуйте доказуемую находку

Замечание содержит условие возникновения, вред, точные строки и минимальное направление исправления. Формулировка «возможно, тут проблема» без пути воспроизведения остаётся вопросом.

Не требуйте от ревьюера писать весь патч. Сначала важно подтвердить дефект и приоритет.

• приоритет и короткий заголовок;
• сценарий возникновения;
• наблюдаемое последствие;
• узкий диапазон строк;
• почему текущий тест не защищает.

5. Проверьте отрицательные сценарии

Повторный запрос, конкурентное действие, неверная роль, чужой идентификатор, timeout и restart часто выявляют то, что happy path скрывает.

Для внешней интеграции проверьте duplicate, retry и частично выполненный эффект.

Что означает отсутствие находок

Это означает, что в просмотренном scope при выбранной глубине не найден конкретный дефект. Это не сертификат безопасности и не доказательство отсутствия ошибок.

Укажите, какие проверки были выполнены и какие зависимости оставались недоступны.

Каркас промпта для ревью

«Проведи review immutable diff [range]. Цель: [результат]. Критические инварианты: [список]. Ищи defects по порядку [риски], включая [негативные сценарии]. Для каждой находки дай приоритет, сценарий, вред и точные строки. Не меняй код и не перечисляй чисто стилевые пожелания. Если находок нет, укажи фактические проверки и границы».

Effort помогает структурировать запрос, но качество ревью зависит от доступного кода, контрактов и проверки выводов.