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

08. Code review (/review)

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

Зачем

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

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

text
/review

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

text
Выбор режима ревью
  → Проверить относительно базовой ветки   (стиль PR)
    Проверить незакоммиченные изменения
    Проверить коммит
    Свои инструкции для ревью

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

1. Проверить относительно базовой ветки (стиль PR)

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

text
Выбор базовой ветки
  → main
    develop
    origin/main
    feat/auth-prep

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

2. Проверить незакоммиченные изменения

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

3. Проверить коммит

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

4. Свои инструкции для ревью

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

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

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

Inline-аргумент

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

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

Что в отчёте

Ревьюер возвращает структурированный отчёт в полноэкранном pager'е:

text
─ Code Review — main ↔ feat/auth-redux · 5a3f12d ──

  Summary                                           
    Reviewed 8 files (+342, -148 lines).            
    Found 2 critical, 5 important, 4 suggestions.   

  Critical                                          
    [1] src/auth.rs:42 — SQL injection risk         
        verify_user uses string concatenation.      
        Use prepared statements.                    

    [2] src/auth.rs:88 — Plaintext password log     
        Token includes user password.               
        Mask before logging.                        

  Important                                         
    [3] src/handlers.rs:156 — missing error context 
    [4] tests/auth_tests.rs — no negative cases     
    ...                                             

  Suggestions                                       
    [8] src/utils.rs:23 — extract helper            
    ...                                             

↑↓ scroll · q close                                 
─────────────────────────────────────────────────────

Каждая находка — со ссылкой на файл и строку (clickable в большинстве терминалов).

Локализация отчёта (с 0.4.11): под /locale ru заголовки находок (title), описания (body) и общий комментарий (overall_explanation) приходят на русском. JSON-схема ответа, пути файлов и сниппеты кода остаются на английском — это намеренно, чтобы grep'ать и копировать в IDE.

Работа с findings

После закрытия отчёта вы возвращаетесь в чат. Дальше — как обычно:

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

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

text
Все findings из категории "important" — посмотри и поправь.

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

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

Ревью можно настроить под задачу:

text
/review проверь только тесты — coverage и edge-cases
/review безопасность: input validation, auth, XSS, SQL
/review performance: N+1 queries, allocations в hot path
/review readability: длинные функции, плохие имена, дублирование
/review backwards compatibility: что я мог сломать публичного API

review_model

/review может использовать отдельную модель, не ту, что у вас в основной сессии. Полезно, если основная — дешёвая (для быстрых правок), а на ревью хочется сильную (для качества).

В ~/.astracode/config.toml:

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

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

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

При установленных code-review-скиллах ревью становится мощнее:

Скилл Что добавляет
code-review Базовая методология ревью
code-review-breaking-changes Поиск breaking changes в API
code-review-change-size Анализ размера PR (если слишком большой)
code-review-context Учёт контекста (что вы пытались сделать)
code-review-testing Качество тестов, coverage

Скиллы лежат в <repo>/.astracode/skills/ или ~/.astracode/skills/. Подробнее — 10-skills.md.

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

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

text
1. /diff             — посмотреть, что у вас вообще в diff'е
2. /review           — против main
3. Поправить critical / important
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

Если в отчёте что-то непонятно:

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

Откроется sub-разговор, ответ не загрязнит основной. См. 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