0.4.11
Поиск по документации… ⌘K
08 · Руководство пользователя

08. Code review (/review)

/review запускает агента-ревьюера — он смотрит на ваш код «свежим глазом», ищет баги, упрощения, проблемы. Результат приходит в виде отчёта.

Зачем

  • Перед коммитом — поймать мелкие ошибки до того, как кто-то увидит.
  • Перед PR — улучшить качество кода.
  • После рефакторинга — убедиться, что ничего не сломалось.
  • При unsure — «я не уверен, что сделал правильно, проверь».

Базовое использование

text
/review

Откроется меню из четырёх целей:

text
What to review?
  → Against a base branch         (PR-style)
    Uncommitted changes
    A commit
    Custom review instructions

Стрелками выбрать, Enter — запустить.

1. Against a base branch (PR-style)

Сравнение HEAD с базовой веткой:

text
Choose base branch:
  → main
    develop
    origin/main
    feat/auth-prep

Выберите — ревьюер пройдётся по diff'у HEAD ↔ base. Это самый частый случай — то же, что увидит ревьюер вашего PR.

2. Uncommitted changes

Ревью текущих несохранённых изменений (git diff + untracked файлы). Полезно перед git add.

3. A commit

Выбрать конкретный коммит (показывается picker последних). Ревью изменений в нём.

4. Custom review instructions

Введите свободный текст:

text
Сфокусируйся на безопасности: SQL injection, XSS, неэкранированный input.

Используется как промпт для ревьюера. Можно задавать конкретные критерии.

Inline-аргумент

Сразу запустить custom-ревью без меню:

text
/review проверь безопасность, особое внимание — input validation
text
/review только тесты — что покрыто, что нет
text
/review focus on performance issues, especially in hot loops

Что в отчёте

Ревьюер возвращает структурированный отчёт прямо в чат (как обычное agent-сообщение):

text
Review comments:

- SQL injection risk — src/auth.rs:42-58
    verify_user uses string concatenation.
    Use prepared statements.

- Plaintext password log — src/auth.rs:88-92
    Token includes user password.
    Mask before logging.

- missing error context — src/handlers.rs:156
- no negative cases — tests/auth_tests.rs
...

Отчёт состоит из общего объяснения (если есть) и плоского списка находок. Каждая находка — заголовок, ссылка на файл и строки, затем тело комментария. У находок есть числовой priority и confidence_score, но они не разбиваются по категориям критичности.

Отчёт появляется в истории чата, а не в отдельном pager'е. Прокрутка — обычная для истории чата.

Работа с findings

После отчёта в чате дальше — как обычно:

text
По первой находке (SQL injection в auth.rs:42) — давай fix.

Модель прочитает находку, посмотрит код, предложит изменение.

text
Все findings с высоким приоритетом — посмотри и поправь.

Так можно итерировать. Когда поправили — снова /review, убедитесь, что критических больше нет.

Кастомные фокусы ревью

Ревью можно настроить под конкретные задачи через inline-аргумент или скиллы (см. ниже). Например:

text
/review только тесты — что покрыто, что нет

Отдельная модель для ревью

В config.toml:

toml
model = "claude-haiku-4-5"           # быстрая и дешёвая для повседневной работы
review_model = "claude-sonnet-4-6"   # сильная для ревью

Если review_model не задан — используется текущая модель сессии.

Связь со скиллами

Ревью можно усилить, подключив сторонние скиллы из репозитория сообщества или написав свой (см. 10-skills.md). Встроенных code-review-скиллов в поставке нет — ревьюер работает на системном промпте и настройках модели.

Workflow рекомендации

Перед каждым PR

text
1. /diff             — посмотреть, что у вас вообще в diff'е
2. /review           — против main
3. Поправить находки с высоким приоритетом
4. /review           — повторить, убедиться, что чисто
5. !git commit -m "..."
6. !git push

Когда сами не уверены

text
Я не уверен, правильно ли я сделал OAuth. Запусти /review с фокусом на безопасности.

Модель сама выполнит /review с подходящим промптом.

При большом PR

Если diff больше ~1000 строк — ревьюер может пропускать детали. Стратегия:

text
/review change-size first

Покажет, что diff большой, и предложит разбить на части. Тогда:

text
/review only the changes in src/auth/

Сфокусированное ревью одного модуля.

Что НЕ делает /review

  • Не пушит изменения. Только показывает отчёт.
  • Не применяет findings автоматически — вы решаете, что чинить.
  • Не запускает ваши тесты — но если попросите, может (отдельным запросом).
  • Не гарантирует, что найдёт все баги — это LLM, она ошибается.

Side conversation внутри review

Пока идёт code review, /side недоступна — ревью-режим не принимает побочных разговоров. Если в отчёте что-то непонятно, сначала закройте отчёт (q/Esc), вернитесь в обычный чат, и уже там спросите через /side:

text
/side что такое "missing error context" в Rust?

См. 09-side-conversations.md.

/autoreview

Если используете режим auto-review approvals (см. 13-safety.md), модель сама ревьюит свои действия перед выполнением. Иногда auto-reviewer отказывает («рискованно»). Если вы уверены — /autoreview разрешает один повтор.

Лимиты

  • Очень большой diff (>5000 строк) — ревьюер может пропустить детали или вернуть только high-level отчёт.
  • Сложные cross-file связи — поймает не всегда.
  • Логические ошибки без типов — модели лучше с типизированными языками (Rust, TypeScript).

Поэтому /review — дополнение к человеческому ревью, а не замена.

Best practices

✓ Ревью часто, мелко — после каждой логической части, а не раз в неделю.
✓ С фокусом — /review безопасность, /review только тесты — точнее, чем «посмотри всё».
✓ С отдельной моделью — review_model = "claude-sonnet" для сложных проверок.
✓ Перед коммитом, не после — поправить дешевле, пока не запушено.
✗ Не верить на 100% — ревью находит много, но не всё. Финальная ответственность — на вас.
✗ Не запускать на огромных diff'ах — разбейте.

Связанные команды

  • /diff — посмотреть diff перед ревью.
  • /plan — спланировать ДО написания (превентивный «ревью»).
  • /goal — задача с обязательным ревью на финале.
ESC