Рабочий процесс Claude Code для предпросмотра PR: заранее проверить читаемость, корректность и граничные случаи, затем сгенерировать чеклист ревьюера и вопросы для автора.
You are doing a pre-review of a pull request.
Context
Input
Output format
Rules
\n\nДля изменений с высоким риском (аутентификация, платежи, права, миграции) добавьте фокус на отказ и откат:\n\ntext
Extra focus for this review:\n\nДля рефакторов сделайте правило «поведение не должно меняться»:\n\ntext
This PR is a refactor. Assume behavior must be identical.\n\nЕсли нужна быстрая проверка, добавьте лимит: «Ответь в менее чем 200 слов». Если нужна глубина — попросите «до 10 находок с обоснованием».\n\n## Превратите вывод в чеклист ревьюера\n\nЗаметки Claude становятся полезными, когда их переводят в короткий чеклист, который человек может закрыть. Не пересказывайте дифф. Зафиксируйте риски и решения.\n\nРазделите элементы на две корзины, чтобы обсуждение не превратилось в споры о предпочтениях:\n\n**Нужно исправить (блок мерджа)**\n- [ ] Корректность: ожидаемый результат описан в одном предложении и совпадает с тикетом\n- [ ] Граничные случаи: пустые/null входы и пути ошибок обработаны (или явно отклоняются)\n- [ ] Безопасность данных: записи и миграции безопасны для существующих данных и старого кода\n- [ ] Тесты: как минимум один тест покрывает основное поведение и один — самый рискованный сбой\n- [ ] Наблюдаемость: логи/метрики достаточны для быстрой отладки (request id, user id, job id)\n\n**Хорошо бы сделать (после релиза или отдельным PR)**\n- [ ] Читаемость: переименовать самый запутанный идентификатор или добавить короткий комментарий «почему»\n- [ ] Согласованность: привести к существующим паттернам ошибок, нейминга и структуры файлов\n- [ ] Производительность: отметить изменения в горячих путях и имеют ли они значение при текущем масштабе\n- [ ] Документация: обновить inline‑доки, если добавлен новый флаг/опция\n\nТакже зафиксируйте готовность к релизу: порядок безопасного деплоя, что смотреть после релиза и как откатить изменение.\n\n## Вопросы перед мерджем\n\nПредпросмотр помогает только если он завершаетcя небольшим набором вопросов, которые требуют ясности.\n\n### Поведение и корректность\n\n- Что меняется видно пользователю и что должно оставаться прежним?\n- Если это «без изменения поведения», какие доказательства показывают идентичность выходов?\n- Какой самый вероятный продовый провал и где он проявится (UI, API, данные)?\n- Какие предположения делает код о входах, порядке, времени или сетевых вызовах?\n- Есть ли ошибки, которые поглощаются или заменяются на молчащие дефолты?\n\n### Граничные случаи, тесты и операции\n\n- Какие реальные худшие входы (пустые, огромные, испорченные, дубли) и что должно происходить?\n- Какой обычный поток может вызвать это повторно (повторы, двойной клик, фоновые задачи), и безопасно ли это?\n- Какой тест доказывает основное поведение, а какой покрывает самый рискованный случай?\n- Если теста нет, сложно ли его написать или код сложно тестировать?\n- Что потребуется ops: полезные логи, метрики, алерты, дефолты конфигураций и шаги отката?\n\nЕсли вы не можете ответить этими простыми словами, приостановите мердж и сократите область изменений или добавьте доказательства.\n\n## Частые ловушки (и как их избежать)\n\nБольшинство провалов — это проблемы процесса, а не модели.\n\n- **Вставляют огромные диффы без фокуса.** Попросите ревью по 1–3 рискованным зонам и вставьте только связанные хунки плюс сигнатуры, от которых они зависят.\n- **Пропускают намерение и ожидаемое поведение.** Без цели ревью расплывается. Добавьте две строки: что меняется и что не должно меняться.\n- **Доверяют уверенным предположениям.** Требуйте цитирования строк из диффа. Если нельзя сослаться на доказательство, считайте это гипотезой, которую нужно проверить.\n- **Уходят в велосипеды со стилем.** Попросите разделять «Нужно исправить» и «Хорошо бы», и ограничьте замечания по стилю.\n- **Игнорируют командные стандарты.** Если у команды есть соглашения (ранние return, типы ошибок, формат логов), включите их.\n\nЕсли PR добавляет новый checkout‑эндпоинт, не вставляйте весь сервис. Вставьте хэндлер, валидацию, запись в БД и любые изменения схемы. Затем скажите: «Цель: предотвратить двойные списания. Не цель: переименовать поля.» Вы получите меньше комментариев, и их будет проще проверить.\n\n## Реалистичный пример: предпросмотр маленького PR\n\nНебольшой, жизненный PR: добавить поле «display name» в экран настроек. Он затрагивает валидацию (сервер) и текст UI (клиент). Достаточно мал, чтобы всё обдумать, но всё равно полно мест, где прячутся баги.\n\nВот какие фрагменты диффа вы вставите (плюс 2–3 предложения контекста: ожидаемое поведение и связанные тикеты):\n\ndiff\n```diff
- <TextInput label="Name" value={name} />
+ <TextInput label="Display name" value={displayName} helperText="Shown on your profile" />
```\n\nПример находок, которые вы хотите получить обратно:\n\n- Читаемость: в разных файлах смешиваются «displayName» и «name». Выберите один термин, чтобы будущие изменения не требовали мысленного перевода.\n- Корректность: сервер валидирует длину, а клиент — нет. Пользователи могут ввести 1–2 символа и увидеть ошибку только после отправки.\n- Граничный случай: строки, состоящие только из пробелов, проходят проверку len(displayName), но выглядят пустыми. Тримьте перед валидацией.\n\nПереведите это в чеклист:\n\n- Имена согласованы между API, полями БД и UI‑лейблами.\n- Клиентские проверки соответствуют серверным правилам (мин/макс, обязательность).\n- Ввод тримится (и поведение с Unicode/emoji приемлемо).\n- Сообщения об ошибках понятны и согласованы между сервером и UI.\n\n## Быстрые проверки, метрики и дальнейшие шаги\n\nClaude Code PR‑ревью наиболее полезно, когда оно заканчивается несколькими быстрыми проверками:\n\n- Поведение: что меняется для пользователя и что не должно меняться\n- Тесты: что покрыто, что отсутствует, что может флакать\n- Логи и ошибки: отказы понятны и сообщения пригодны для отладки\n- Производительность: новые циклы, N+1‑запросы, большие полезные нагрузки, дополнительные сетевые вызовы\n- Безопасность: валидация, проверки авторизации, секреты, рискованные дефолты\n\nЧтобы понять, окупается ли это, отслеживайте две простые метрики в течение 2–4 недель: время ревью (от открытия до первого содержательного комментария и от открытия до мерджа) и доработки (последующие коммиты после ревью или сколько комментариев потребовали изменение кода).\n\nСтандартизация важнее идеальных промптов. Выберите один шаблон, требуйте короткий блок контекста (что изменилось, зачем, как тестировать) и договоритесь, что значит «готово».\n\nЕсли ваша команда разрабатывает через чат, тот же поток работает и в Koder.ai: генерируйте изменения, экспортируйте исходники и прикрепляйте предпросмотр‑чеклист к PR, чтобы человеческое ревью оставалось сосредоточенным на самых рискованных местах.