> ## Documentation Index
> Fetch the complete documentation index at: https://docs.qodo.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Apply REVIEW.md instructions to code review

> Learn how to use REVIEW.md to define repository-specific review guidance that Qodo applies during automated code review, helping review agents prioritize findings, reduce noise, and enforce your team's engineering standards.

<Badge color="outline-purple" size="sm" shape="pill">Research Preview</Badge>

Qodo uses your `REVIEW.md` file to apply repository-specific review guidelines during automated code review. It acts as a repository-level instruction file that influences what the review agents flag, how findings are prioritized, and what feedback is returned on every pull request.

## What is REVIEW\.md?

`REVIEW.md` is a file committed at the root of a repository (one per repository) that lets teams define project-specific review guidelines for Qodo's automated code review. It shapes what the review agent flags, how it prioritizes findings, and what findings show up on every pull request. It refines the review process rather than replacing it.

Use `REVIEW.md` to define repository-specific review guidance that Qodo's review agents follow during every code review. This guidance refines review output and adjusts review emphasis without affecting coding assistants.

Unlike general project documentation, `REVIEW.md` is only used by the code review agents.

## Why use REVIEW\.md?

By default, automated reviews are designed to work across a wide range of codebases. However, every codebase is different.

`REVIEW.md` helps teams:

* Align reviews with internal engineering standards
* Avoid irrelevant or low-value comments
* Increase the signal-to-noise ratio in pull request feedback
* Encode architectural or business rules directly into review behavior
* Ensure consistent enforcement across all repositories and reviewers

In practice, it turns code review from a generic linting-style system into a team-aware reviewer.

## Enable REVIEW\.md enforcement

To enable `REVIEW.md` enforcement for a repository:

1. Log in to the Qodo portal.
2. Navigate to **Configuration** > **Code review**.
3. Enable the **REVIEW\.md instructions** toggle.

Once enabled, Qodo will use the repository's `REVIEW.md` file to guide code review findings.

## How it works

When a review is triggered:

1. Qodo scans the diff and surrounding code context.
2. The review engine loads `REVIEW.md` from the repository root.
3. All review agents, including issue detection, compliance, skills, specification, and persona analysis, use the repository's `REVIEW.md` instructions when generating findings.
4. Agents analyze the pull request according to those rules.
5. Findings are returned as inline comments and grouped summaries.

If `REVIEW.md` is updated, the next pull request review automatically reflects the new rules.

## View REVIEW\.md findings

When `REVIEW.md` enforcement is enabled, any violations of rules defined in `REVIEW.md` are surfaced as findings in pull requests.

You can view these findings:

* As inline comments on the relevant code changes
* In the findings panel alongside other code review findings

`REVIEW.md` findings are evaluated together with Qodo's standard review checks, helping ensure pull requests comply with your repository-specific review requirements.

## Basic structure of REVIEW\.md

`REVIEW.md` is written in plain Markdown and has no required schema. You can organize it using standard Markdown headings and lists.

### Example

```markdown theme={null}
# Code Review Rules

## Severity rules

Treat the following as Important issues:
- Security vulnerabilities
- Data loss risks
- Broken business logic
- Incorrect API behavior

Treat the following as Nit:
- Naming inconsistencies
- Minor refactoring suggestions
- Formatting improvements not enforced by CI

## Noise control

- Limit to 5 Nit comments per PR
- Group repetitive issues into a single summary note

## Always verify

- Database queries must be scoped to tenant
- API endpoints must include authentication checks
- New features must include tests
```

## Customization areas

| Area                          | Description                                                                           | Example                                                                                                    |
| ----------------------------- | ------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------- |
| **Severity mapping**          | Define which findings should be treated as critical issues versus minor suggestions.  | Security vulnerabilities: **Important**; naming inconsistencies: **Nit**                                   |
| **Noise reduction**           | Control how much feedback is returned in each review to keep findings actionable.     | Limit Nit comments to five per pull request; group similar findings into a summary.                        |
| **File and path exclusions**  | Exclude files or directories that should not be reviewed or require reduced scrutiny. | Generated code, lockfiles, vendor dependencies                                                             |
| **Repository-specific rules** | Enforce engineering standards and requirements unique to your codebase.               | Require authentication on new endpoints; require tests for new features                                    |
| **Review focus adjustment**   | Direct the review system to prioritize specific types of issues.                      | Focus on security risks, business logic correctness, performance regressions, or architectural consistency |

## Best practices

Keep `REVIEW.md`:

* **Concise:** Focus on behavior-changing rules.
* **Specific:** Describe what should be flagged.
* **Repository-specific:** Avoid guidance already enforced by linters or formatting tools.
* **Stable:** Frequent changes can lead to inconsistent review behavior.