CLI, хук и MCP

Одна политика — две точки контроля. Бот проверяет MR/PR и остаётся независимым гейтом; те же правила команды и тот же судья доступны агенту прямо в редакторе — до того, как код уедет на ревью.

Сначала выберите свой случай

Дальше всё одинаково — установка, команды, хук, MCP. Различается ровно одно: где берётся доступ к модели. Выберите строку, которая описывает вас, и настройте только её.

Установка

Один файл без зависимостей: ни Node, ни Docker не нужны. Требуется git в PATH — бинарь его в себе не несёт.

Контрольные суммы — в файле SHA256SUMS рядом с артефактами. Сверяйте их: вы запускаете исполняемый файл, скачанный из сети.

Те же файлы выложены релизом на GitHub — байт в байт, с теми же контрольными суммами. Берите то, что быстрее; если сайт недоступен, релиз всё равно на месте.

curl -fsSLO https://reviewgate.dev/dl/reviewgate-latest-darwin-arm64.xz
curl -fsSLO https://reviewgate.dev/dl/SHA256SUMS
shasum -a 256 -c SHA256SUMS --ignore-missing

# no xz? brew install xz
xz -d reviewgate-latest-darwin-arm64.xz
chmod +x reviewgate-latest-darwin-arm64
sudo mv reviewgate-latest-darwin-arm64 /usr/local/bin/reviewgate

curl -fsSLO https://reviewgate.dev/dl/reviewgate-latest-linux-x64.xz
curl -fsSLO https://reviewgate.dev/dl/SHA256SUMS
sha256sum -c SHA256SUMS --ignore-missing

xz -d reviewgate-latest-linux-x64.xz
chmod +x reviewgate-latest-linux-x64
sudo mv reviewgate-latest-linux-x64 /usr/local/bin/reviewgate

# PowerShell. Windows cannot unpack .xz out of the box — take 7-Zip (winget install 7zip.7zip)
curl.exe -fsSLO https://reviewgate.dev/dl/reviewgate-latest-win-x64.exe.xz
curl.exe -fsSLO https://reviewgate.dev/dl/SHA256SUMS

# the hash must appear in SHA256SUMS — an empty output means it does NOT match
$hash = (Get-FileHash reviewgate-latest-win-x64.exe.xz -Algorithm SHA256).Hash.ToLower()
Select-String $hash SHA256SUMS

& "$env:ProgramFiles\7-Zip\7z.exe" x reviewgate-latest-win-x64.exe.xz
Rename-Item reviewgate-latest-win-x64.exe reviewgate.exe
# move reviewgate.exe to a directory on PATH, e.g. %LOCALAPPDATA%\Programs

Свой ключ

Ключ провайдера берётся из окружения процесса или из вашего файла настроек в домашнем каталоге — но никогда из рабочей копии. Это граница безопасности: клон чужого репозитория не должен уводить ваш дифф на чужой endpoint.

export LLM_API_KEY=...        # your provider key
export LLM_JUDGES=...         # optional: a default judge (without one, a single pass)

Чтобы не задавать переменные в каждой сессии терминала, положите их в файл. Объявленные там generators / judges задают вашу схему для локальных прогонов — она замещает командную целиком (берётся как единое целое, генераторы обязательны), отчёт говорит об этом, а --team-llm прогоняет ролями команды. Подробнее: домашний конфиг.

llm:
  api_key: sk-...
  generators:                   # your schema for local runs: taken as a whole,
    - model: claude-sonnet-5    # it replaces the team llm.* from the repo config
  judges:                       # (--team-llm runs with the team schema instead)
    - model: claude-opus-5
  # base_url: https://llm.вашакомпания.ru/v1   # корпоративный шлюз, если он есть

Секрет можно не хранить в открытом виде: вместо api_key укажите api_key_command — команду вашего менеджера паролей. Её вывод нигде не сохраняется.

llm:
  api_key_command: op read op://dev/anthropic/credential

Через сервер команды

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

server:
  url: https://bot.вашакомпания.ru
  gitlab_token: glpat-...   # your personal GitLab token
  # gitlab_token_command: pass show work/gitlab   # or this way, without storing it in the file

Дифф собирается у вас локально; на сервер уходят изменённые файлы, а остальное он дозапрашивает по мере надобности — ровно то, что реально понадобилось судье. Флаг --local возвращает прогон на ваш собственный ключ: пригодится вне сети компании. Как включить режим на сервере — отдельная страница для того, кто выдаёт доступ.

Первый прогон

reviewgate doctor      # check the environment before the first run
reviewgate rules       # which team standards were read
reviewgate review      # review the uncommitted changes

doctor проверяет окружение и говорит, чего не хватает, до того как вы потратите время и токены: он называет источник каждого значения и, в режиме сервера, живьём проверяет доступ. rules показывает, какие правила прочитаны из .reviewgate/config.yml — тот же файл, по которому работает бот.

Дальше бинарь объясняет себя сам: reviewgate help — обзор всех команд и флагов, reviewgate help review — подробно по одной. Те же сведения с примерами и ссылками — в справочнике CLI.

Машинный режим

С --json в stdout уходит только отчёт, всё остальное — в stderr. Коды возврата детерминированные: 0 — гейт пройден или выключен, 2 — есть находки не ниже порога, 1 — сбой (объект ошибки уходит в stdout, если задан --json, иначе текст в stderr). Порог по умолчанию берётся из политики команды, а она из коробки severity_gate: off — то есть без --fail-on код всегда 0.

reviewgate review --json --fail-on major

Поля отчёта, коды ошибок и рецепты для CI — в справочнике CLI.

Хук: ревью перед push

Хук перехватывает git push у агента и не даёт отправить изменения с блокирующими находками. Замер показал, что ставить гейт стоит именно на push, а не на каждый ответ агента: экономить надо на частоте вызова, а не на глубине проверки.

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [{ "type": "command", "command": "reviewgate review --hook-stdin" }]
      }
    ]
  }
}

Порог блокировки — тот же, что у команды: хук читает severity_gate из конфига репозитория, поэтому решение перед push и вердикт бота на MR/PR совпадают. Единственное исключение — гейт, выключенный политикой (severity_gate: off, это дефолт): тогда хук применяет свой порог major и сообщает об этом, иначе он не блокировал бы никогда и был бы бесполезен. Свой порог на один запуск задаётся --fail-on. Диалекты ответа — в справочнике.

Если вы вешаете хук не на push, а на завершение работы агента (событие Stop), цикла не будет: раннер помечает такое повторное событие признаком «продолжаю из-за твоей блокировки», и на нём ReviewGate пропускает прогон вместо того, чтобы снова ревьюить. Иначе находка, которую агент не может или не хочет устранить, крутила бы «стоп → ревью → блокировка → стоп» без потолка, сжигая по полному прогону за виток.

MCP: агент зовёт ревью сам

Два инструмента: review_changes — проверить изменения, get_team_rules — узнать стандарты команды до написания кода, а не из ревью после. Если config.yml у проекта есть, но не разобран, get_team_rules скажет об этом прямо: «правил нет» и «правила не применились» — разные ответы, и агент должен их различать.

{
  "mcpServers": {
    "reviewgate": { "command": "reviewgate", "args": ["mcp"] }
  }
}

Или поставьте из MCP Registry

Сервер опубликован в официальном MCP Registry под именем dev.reviewgate/reviewgate. Клиент, умеющий ставить из реестра (или принимающий бандлы .mcpb — например, Claude Desktop), получает самодостаточный пакет: бинарь внутри, инструменты объявлены, форма настройки — путь к конфигу и ключ модели. У каждого бандла есть fileSha256, и клиент сверяет с ним скачанное. Бандл — на каждую платформу свой: берите под вашу ОС и архитектуру; те же файлы приложены к GitHub Releases.

Подключить сервер мало: агент должен знать, что инструменты есть

Многие клиенты — в их числе Claude Code — грузят описания MCP-инструментов лениво: на старте сессии агент видит имя сервера, но не его инструменты, и просто не догадывается их позвать. Инструмент, которого нет в контексте, не будет вызван, каким бы точным ни было его описание. Лечится двумя строками в файле-инструкции проекта (CLAUDE.md, .cursorrules — смотря чем пользуется ваш агент):

The standards of this project come from the `mcp__reviewgate__get_team_rules` tool —
call it BEFORE writing code, instead of reading the ADRs by hand.

Before finishing a task and before `git push`, check the changes with the
`mcp__reviewgate__review_changes` tool — it is the same judge and the same rules
that check the pull request.

Разница измеримая. На проекте с восемью ADR мы попросили агента выяснить стандарты команды перед написанием кода, не упоминая ReviewGate: без этих строк он около трёх минут читал документы и код вручную; с ними — позвал get_team_rules на шестнадцатой секунде и получил тот же ответ вдвое дешевле. Правила при этом приходят из одного источника, а не восстанавливаются по коду с риском ошибиться.

Второй барьер: клиент спросит разрешение на вызов

Инструменты MCP — сторонний код, поэтому при первом обращении клиент спрашивает у человека, можно ли его звать. В обычной сессии это диалог: выбираете «разрешить», и дальше работает (вариант «разрешить всегда» клиент запоминает в настройках проекта). А вот в неинтерактивном запуске — claude -p "…", прогон из CI, любой скрипт — диалог показывать негде и некому нажимать.

Лечение — перечислить инструменты при запуске либо один раз выдать разрешение в обычной сессии, после чего неинтерактивные прогоны пойдут без флагов. Имена собираются из имени сервера в вашей конфигурации: назвали сервер reviewgate — инструменты зовутся mcp__reviewgate__review_changes и mcp__reviewgate__get_team_rules.

# one-off: list the tools at startup
claude -p "check the uncommitted changes" \
  --allowedTools mcp__reviewgate__review_changes mcp__reviewgate__get_team_rules

# once and for all: grant the permission in an ordinary session
# and the client remembers it for this project
claude

Механизм у каждого клиента свой: приведённый флаг — из Claude Code, в других агентах ищите «tool permissions» или «allowed tools». Общее одно: сервер, которому не разрешили работать, молчит не громче, чем сервер, который не подключён, — и отличить эти два случая можно только по наличию вызова в протоколе.

Что происходит во время прогона

Ревью идут по одному: второй вызов ждёт первого, а не делит с ним бюджет и лимиты провайдера. Канал при этом свободен — короткие методы протокола отвечают сразу, и клиент видит, что сервер жив.

Отмена работает. Агент прекратил вызов (пользователь нажал Esc, задача снята) — прогон останавливается, и ответ на отменённый вызов не отправляется. Честная граница: ответ, который модель уже начала, провайдер посчитает в любом случае; экономия в том, что не начинаются следующие вызовы — судья, ансамбль, арбитр. То же и при закрытии соединения: заказчика нет — считать не для кого.

Ошибка инструмента приходит с isError: true, а в тексте — тот же объект reviewgate.error/v1 с кодом, что печатает CLI (полный список — на странице CLI). Агенту есть по чему ветвиться, и разбирать сообщение регулярками не нужно.