> ## 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. 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 **Configurations** > **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} # REVIEW.md ## Out of scope Don't raise findings here: `scripts/` (local tooling), `**/*_generated.*`, `tests/fixtures/`. ## Layering & dependency direction Layers are `domain → application → infrastructure`; dependencies point inward only. - `domain/` never imports `infrastructure/` — no DB clients, SDKs, or framework types in business logic. It needs one? That's an interface the outer layer implements. - Framework/vendor types (request objects, ORM entities) stay at the edges; map them at the boundary. ## Extension points ("add one of many") Register-and-wire patterns (handlers, event types, providers). A missed wiring spot degrades **silently**, not with an error. - Mirror every hit: `grep -rn` an existing sibling and match each — registration, routing, serialization, metrics, docs. - The new case honors the same contract as its peers (config, error handling, output shape). ## Abstractions & interfaces Program to interfaces; branching on a concrete type rots the moment a new implementation appears. - Dispatch on capability, **never** on concrete type (`isinstance` / class-name switches). - Advertised ≠ implemented — if an implementation opts out of part of the interface, callers check support and degrade first. ## Trust & data boundaries Validate and authorize where *untrusted data enters*, before it reaches core logic. - Every entry point (API, webhook, queue, imported file) validates shape/range and checks authorization at the boundary. - Authorization is about the *resource*, not just the session — an authenticated caller isn't automatically entitled to this record. - **Fail closed** — on any error or unknown case, deny. ## Cross-service / cross-repo contracts Some changes are only correct if a matching change lands where the diff can't reach. - Shared shapes (API fields, event payloads, schemas) change in lockstep across every producer and consumer — name the counterpart repos. - Roll out compatibly: add before you remove, tolerate both shapes during the transition, then clean up. Shims have a removal plan. ## State, ownership & lifecycle Invariants that span methods and files, so any single hunk looks fine. - **Single source of truth** — derived state isn't cached somewhere it can drift. - Resources (connections, locks, handles) are released on every path, including errors. - Idempotency where delivery isn't exactly-once — retries and replays must not double-apply. ## Reuse before reinvention Duplication passes review because the original is off-screen. - Search shared utilities before adding new parsing/formatting/HTTP logic. - One config key per concept — don't reintroduce a knob under a new name. - Extend the existing helper instead of forking a near-copy. ``` ## 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 code behavior changes. * **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. * **Add separately:** Add `REVIEW.md` in its own pull request rather than adding it to an existing pull request. `REVIEW.md` instructions apply to reviews triggered after the file is added. If you add `REVIEW.md` to an already open pull request, Qodo reviews only the current diff and does not re-review the entire pull request using the new instructions.