packages/kilo-docs/pages/automate/code-reviews/overview.md
Kilo's Code Reviews feature automatically analyzes your pull or merge requests using an AI model of your choice. It can review code the moment a PR/MR is opened or updated, surface issues, and provide structured feedback across performance, security, style, and test coverage.
REVIEW.md, including sub-agent usage| Platform | Integration Type | Details |
|---|---|---|
| GitHub | GitHub App | GitHub Setup Guide |
| GitLab | OAuth or PAT | GitLab Setup Guide |
Before enabling Code Reviews:
REVIEW.md file at the repository root to shape how the agent reviews your code.Once configured, the Review Agent runs automatically on PR/MR events. For platform-specific setup, see:
Use REVIEW.md when review policy should live with the repository instead of only in the Kilo dashboard. This is the best place to document domain-specific rules, severity calibration, files to skip, verification expectations, summary style, and how Kilo should use sub-agents.
To use it:
REVIEW.md at the repository root.Kilo reads REVIEW.md from the PR/MR base branch, not the feature branch. That prevents an unreviewed change from rewriting the review policy used to evaluate itself. If the file is disabled, missing, empty, or unreadable, Kilo falls back to built-in guidance. If it is longer than 10,000 characters, Kilo truncates it and notes that in the review summary footer.
By default, Code Reviews uses sub-agents only when they materially improve coverage. After reading the diff, the reviewer estimates changed file count and changed lines, then chooses the largest tier triggered by either signal.
| Diff size | Default behavior | Why |
|---|---|---|
| Tiny: up to 2 files and under 100 changed lines | Use 0 sub-agents and review directly | The coordination cost is higher than the coverage benefit for very small changes. |
| Small: 3-5 files or 100-300 changed lines | Use at most 1 sub-agent for a distinct risky area | One focused second pass can help without creating duplicate or low-signal findings. |
| Medium and larger: 6+ files or more than 300 changed lines | Use the full 6 sub-agents, sharded by independent areas | Larger diffs benefit from parallel coverage across files, domains, and risk categories. |
The reviewer does not spawn sub-agents for a single-file or straightforward typo/config change. Sub-agents are read-only and do not post comments themselves. They return findings with path, line, severity, and rationale. The main reviewer remains responsible for verifying findings, removing duplicates, checking that inline comments target valid diff lines, and posting the final comments and summary.
REVIEW.md can replace the default sub-agent guidance. Use it to change both how many sub-agents Kilo should use and what each one should inspect.
Good sub-agent guidance is explicit about:
Example REVIEW.md section:
## Sub-agent usage
Use 0 sub-agents for docs-only, formatting-only, dependency-lockfile-only, or single-file typo changes.
Use 1 sub-agent for focused changes under 300 changed lines when the diff touches one risky area, such as authentication, billing, database migrations, or security-sensitive parsing.
Use 3 sub-agents when a PR spans API, data model, and UI changes:
1. API/data reviewer: check request validation, authorization, persistence, and migration safety.
2. UI reviewer: check user-visible behavior, accessibility, empty states, and error states.
3. Test reviewer: check that tests cover the observable behavior and important edge cases.
Use the full 6 sub-agents only for large cross-cutting changes, security-sensitive work, or changes above 800 changed lines. Split them by independent domains rather than asking every sub-agent to review the same files.
Each sub-agent must stay read-only, must not post comments, and must return findings with path, line, severity, rationale, and confidence. The main reviewer must verify every finding before posting it.
REVIEW.md can change review policy and sub-agent usage, but it cannot override Kilo's hard safety constraints, read-only mode, non-interactive execution, platform API instructions, diff-line rules, duplicate-comment rules, or output formatting requirements.
Code Reviewer is also available locally. This is valuable for developers who want to review their code before pushing a pull request to their team publicly, or for developers who want reviews and don't need to ship a pull request to GitHub.
{% tabs %} {% tab label="VSCode" %}
Use /review for all local code reviews:
/review — Review uncommitted changes (staged, unstaged, and untracked) when run without arguments/review uncommitted [guidance] — Review uncommitted changes with optional guidance/review branch [base] [guidance] — Review your current branch vs. its detected or specified base, with optional guidance/review <commit-hash> — Review a specific commit/review <PR URL or number> — Review a pull request{% /tab %} {% tab label="CLI" %}
Use /review for all local code reviews:
/review — Review uncommitted changes (staged, unstaged, and untracked) when run without arguments/review uncommitted [guidance] — Review uncommitted changes with optional guidance/review branch [base] [guidance] — Review your current branch vs. its detected or specified base, with optional guidance/review <commit-hash> — Review a specific commit/review <PR URL or number> — Review a pull request{% /tab %} {% /tabs %}
When a pull request or merge request is opened or updated:
Reviews are posted directly in your platform (GitHub or GitLab) as if coming from a team reviewer.
You can tailor what the Review Agent pays attention to:
The Review Agent is ideal for:
REVIEW.md.