# ReviewGate

> AI code review against the standards of one particular team, at two points of control. Point 1 is
> a bot for your repository hosting (self-hosted GitLab or GitHub): it receives a webhook about a
> merge/pull request, reads the diff, runs the review through a model and leaves inline comments and
> a summary. Point 2 is review inside the agent's loop: a CLI, a hook before git push and an MCP
> server, all working from the same team rules and the same judge, but BEFORE the request is opened.
> Everything runs inside the customer's own infrastructure — the code and the diff never go out and
> are never stored, only review metadata is. Any provider: Anthropic, any OpenAI-compatible endpoint,
> Yandex AI Studio, Ollama, vLLM.

If you are an AI agent asked to bring ReviewGate up: start with the installation playbook below. It
is self-contained, the steps are idempotent, and each one ends with a check. Do not invent secrets
(ask a human for the hosting token and the model key) and do not send the customer's code anywhere.

If you are an AI agent that writes code and wants to check itself: you need the «Review in the
agent's loop» section. It installs as a single file, with no Node and no Docker; the rules come from
the `.reviewgate/config.yml` of the repository you are working in.

The product is free. The output language of the bot follows the `language` key of
`.reviewgate/config.yml` and is English by default; the deployment logs an operator reads are always
English and do not follow that key.

This site exists in two languages: English at the root, Russian under `/ru/` (the same page is
`/docs/cli` and `/ru/docs/cli`). Every page declares its counterpart through `hreflang`. The
documents linked below are the English ones — they are the canonical version, and the code
examples inside them are English in both locales. The one artifact that has a Russian
counterpart is the diagnostics script: `/diagnose.ru.sh` prints its findings in Russian.

## Review in the agent's loop (CLI, hook, MCP)

- [CLI, hook and MCP](https://reviewgate.dev/docs/agents): installing the binary,
  `reviewgate review --json` with deterministic exit codes (0 clean · 2 findings at or above
  `--fail-on` · 1 failure), the `git push` hook for Claude Code, configuring the MCP server with the
  `review_changes` and `get_team_rules` tools
- `reviewgate init` creates the missing config skeletons: the repository policy
  (`.reviewgate/config.yml` at the repository root, with a stack preset detected from the
  manifests) and the home config (fully commented out; permissions 600 where the OS enforces
  file modes — Windows does not). Existing
  files are never touched; `--lang ru|en` picks the template language, and outside a terminal
  init never prompts. After it, fill `rules[]` and verify with `reviewgate rules`
- [CLI reference](https://reviewgate.dev/docs/cli): every command and flag, the fields of the
  `reviewgate.report/v1` report, the full list of error codes with a cure for each, the home config,
  and recipes for CI. Branch on `code`, not on the message text. A local run may use the developer's
  own LLM schema from the home config; the report declares that in `run.llmSource` (`home` does not
  predict the bot review; `--team-llm` or the `team_llm: true` tool argument runs with the team schema)
- [Review server for the team](https://reviewgate.dev/docs/review-server): how a team gets review in
  the editor without the model key being handed out
- [Downloads](https://reviewgate.dev/dl/SHA256SUMS): the checksums; the files themselves are at
  `https://reviewgate.dev/dl/reviewgate-latest-<platform>.xz`, where platform is `darwin-arm64`,
  `darwin-x64`, `linux-x64`, `linux-arm64`, `linux-x64-musl` (Alpine) or `win-x64.exe`. You need
  `git` in PATH; verify the checksum before running it
- Call the `get_team_rules` tool BEFORE writing code: writing to the team standards straight away is
  cheaper than learning them from a review afterwards

## Installing through an AI agent

- [Installation playbook (ai-setup.md)](https://reviewgate.dev/ai-setup.md): a step-by-step guide for
  an agent — compose, .env, the webhook through the GitLab API, config.yml, diagnostics, a test
  review. The review concurrency (REVIEW_CONCURRENCY) must be agreed with a human against the size of
  the team rather than left at the default
- [Client docker-compose.yml](https://reviewgate.dev/docker-compose.yml): the minimal set of
  containers (the bot plus Redis, optionally Postgres) for the customer's own infrastructure
- [diagnose.sh](https://reviewgate.dev/diagnose.sh): a self-check script for the
  hosting → webhook → bot → model chain (bash and curl, no dependencies); it also prints the bot
  version. Russian-speaking operators: [diagnose.ru.sh](https://reviewgate.dev/diagnose.ru.sh) —
  the same checks, output and hints in Russian

## Documentation

- [Quickstart](https://reviewgate.dev/docs/quickstart): from nothing to a first review
- [Installation](https://reviewgate.dev/docs/install): docker compose, health, how to learn the
  version of a running bot, the full environment reference
- [Connecting GitLab](https://reviewgate.dev/docs/gitlab): the bot token, the webhook (Merge request
  events plus Comments), which events are reviewed
- [Connecting GitHub](https://reviewgate.dev/docs/github): a GitHub App (permissions: Pull requests
  write, Contents read, Checks write, Issues read, Metadata read) or a PAT, the webhook
  `POST /api/webhooks/github` with an HMAC secret, Content type application/json, the events Pull
  request + Pull request review comment + Issue comment + Pull request review (a mention in the body
  of a review is answered with a separate comment in the conversation — a review body has no thread);
  changing the App permissions requires acceptance on the installation
- [Review configuration](https://reviewgate.dev/docs/config): .reviewgate/config.yml — team rules,
  dont_flag assumptions (they silence false positives), your own prompt, request variables
  ({mr:author} and others), presets, the severity gate, the cost of a review, run diagnostics, reply
  mode (answers in threads), the ❓ question genre (questions: true — non-blocking engineering
  doubts requalified from judge rejects; in the JSON report they arrive as questions[]). The file
  name is config.yml ONLY — a stray config.yaml is not read and is reported with a rename hint;
  when no config exists, the summary honestly says the review ran on default settings. To exclude
  ONE file do not widen `ignore` with a glob — put `reviewgate-ignore-file: <reason>` on its own
  line inside that file, behind a comment; the reason is mandatory, documentation files are not
  scanned, and such a file never reaches the model
- [Config JSON Schema](https://reviewgate.dev/config.schema.json): validate .reviewgate/config.yml
  BEFORE the commit — editor modeline `# yaml-language-server: $schema=https://reviewgate.dev/config.schema.json`,
  CI, or an agent-side check; the schema mirrors the parser (unknown keys, closed rule schema, role
  shapes, caps) and is kept in lockstep by tests. The schema is CLOSED — when writing config.yml,
  do not invent keys that look plausible (`globs`, `prompt`, `when` inside a rule do not exist and
  are NOT applied): a rule has exactly id, description, severity, and every condition or file scope
  is written in plain language inside description (or review_prompt)
- [Models and your own key](https://reviewgate.dev/docs/llm): bring your own key, choosing a model,
  running one locally, proxies, parallel reviews REVIEW_CONCURRENCY (1..64) and a cheat sheet on
  cloud provider limits
- [License](https://reviewgate.dev/docs/license): the product is free and needs no key; the status
  line in the summary and previously issued keys
- [Logs and monitoring](https://reviewgate.dev/docs/logging): the job tag in the logs,
  LOG_FORMAT=json, shipping to Graylog/ELK/Loki
- [Troubleshooting](https://reviewgate.dev/docs/troubleshooting): «no review appeared» — a
  step-by-step breakdown

## For humans

- [What the AI onboarding does](https://reviewgate.dev/docs/ai-setup): what the agent will read, what
  it will ask you for, what it does on its own, and the privacy guarantees