Skip to main content
Research Preview 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

# 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

AreaDescriptionExample
Severity mappingDefine which findings should be treated as critical issues versus minor suggestions.Security vulnerabilities: Important; naming inconsistencies: Nit
Noise reductionControl 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 exclusionsExclude files or directories that should not be reviewed or require reduced scrutiny.Generated code, lockfiles, vendor dependencies
Repository-specific rulesEnforce engineering standards and requirements unique to your codebase.Require authentication on new endpoints; require tests for new features
Review focus adjustmentDirect 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.