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

# Code Review

> Review code behavior with AST-informed context, team knowledge, and checks across repositories

export const ThemeImage = ({src, alt, width}) => {
  let lightSrc, darkSrc;
  if (src.includes("-light.")) {
    lightSrc = src;
    darkSrc = src.replace("-light.", "-dark.");
  } else if (src.includes("-dark.")) {
    darkSrc = src;
    lightSrc = src.replace("-dark.", "-light.");
  } else {
    lightSrc = src;
    darkSrc = src;
  }
  const style = width ? {
    maxWidth: width,
    marginInline: "auto"
  } : undefined;
  return <span>
      <img className="block dark:hidden rounded-lg border" src={lightSrc} alt={alt} style={style} />
      <img className="hidden dark:block rounded-lg border" src={darkSrc} alt={alt} style={style} />
    </span>;
};

## Overview

Gitar reviews PRs using the surrounding code and the team's engineering context. Findings land on the changed lines, with explanations and suggested fixes.

<CardGroup cols={2}>
  <Card title="Security Analysis" icon="shield">
    Vulnerabilities, unsafe patterns, input validation
  </Card>

  <Card title="Bug Detection" icon="bug">
    Logic errors, null pointer risks, edge cases
  </Card>

  <Card title="Performance" icon="gauge">
    Algorithm complexity, database queries, memory usage
  </Card>

  <Card title="Code Quality" icon="sparkles">
    Readability, maintainability, best practices
  </Card>
</CardGroup>

## Beyond the changed lines

Gitar uses [AST-informed code structure](/how-gitar-works#code-structure-informs-the-review) to navigate the implementation, then reads related files and searches for callers to investigate the effect of a change.

| Coverage | What it adds to the review |
| - | - |
| [Agentic Security](/features/agentic-security) | Security review of changes to agent instructions and supporting scripts. |
| [Knowledge](/features/knowledge) | Team conventions learned from instructions and human review feedback, with source citations. |
| [Cross-Repo Analysis](/features/cross-repo-analysis) | Impacts on other repositories, including dependencies across code hosts. |
| [Cross-PR Analysis](/features/cross-pr-analysis) | Logic mismatches between related open PRs, with references to both changes. |
| [Functional Validation](/features/functional-validation) | Objective-by-objective checks against linked issue requirements. |
| [Risk Triage](/features/code-review/risk-triage) | A whole-PR risk assessment shaped by organization and repository policy. |

See [How Gitar Works](/how-gitar-works) for the context used during review, including web documentation and connected knowledge sources.

## Large PRs and review volume

Gitar supports unlimited changed files per PR. Large changes remain eligible for review, including changes spread across a monorepo.

Gitar prioritizes relevant code and condenses repetitive changes to keep large diffs reviewable. Generated files and other low-value content may be excluded from review.

Enterprise includes [unlimited review volume per author](/account-billing/plans#enterprise-scale), including allowed bot authors. Other plans follow the [usage policy](/account-billing/plans#usage-limits).

## How It Works

Code reviews run automatically when:

* A new pull request is created
* New commits are pushed to an open PR

Gitar skips a PR containing only a single revert commit. This also applies when the original change was never reviewed by Gitar.

Push any commit beyond the revert and Gitar reviews the pull request as usual, because at that point it is no longer a plain revert. Everything else still runs either way, including CI analysis and rule evaluation.

## Review depth

Review depth controls which verified findings Gitar reports.

| Setting | What to expect |
| - | - |
| Focused | Prioritizes higher-impact findings. |
| Thorough | Includes smaller verified issues, with more comments to assess. |

Enterprise organization admins choose the default under **Settings -> Configuration -> Review depth**. To set a different depth for a repository, select **Customize** on its row and choose **Focused** or **Thorough**. Changes take effect on the next review, including existing PRs.

Repositories inherit the organization default until an override is saved. Resetting an override restores inheritance. Previously saved review depth settings are retained.

## Custom Code Review Instructions

Add your own rules, checks, or gotchas to tailor the review to your project. Commit a markdown file under the **`.gitar/review`** directory. Use several files to organize instructions by topic.

Gitar's own repository, for example, has a `gitar-gotchas.md` covering conventions specific to that codebase. One of them is to use `info!` for logging that needs operational visibility and leave `debug!` for local debugging, since its telemetry only renders logs at severity `info` or higher.

One file can pull in another with the `@` syntax, so shared guidance lives in one place. See [Custom Review Instructions](/configuration/repository-config#custom-review-instructions) for the directory layout and include resolution.

## Review Output

Gitar publishes review feedback in two places on your PR:

* **Inline review comments**: every unresolved finding is posted on the exact file and line it applies to, so feedback lands where you're reading the code.
* **Dashboard comment, Code Review section**: a consolidated view on the Gitar dashboard comment showing the overall verdict, severity breakdown, and resolved-finding tracking.

The dashboard comment is the single source of truth for the overall state of a PR, holding the code review summary, CI analysis, and rule evaluations in one place. When you push new commits, Gitar updates that comment instead of posting a new one, so your PR timeline stays clean.

Resolved findings move into a collapsible section as you push fixes, so what is left to address stays at the top.

The **Cross-Repo** and **Cross-PR** categories only appear when [Cross-Repo Analysis](/features/cross-repo-analysis) or [Cross-PR Analysis](/features/cross-pr-analysis) is turned on for your organization.

To change how that summary reads, set [review summary instructions](/configuration/settings#review-summary-instructions) for your organization.

<ThemeImage src="/assets/images/code-review-comment-light.png" alt="Code Review in Dashboard Comment" />

Each finding includes:

* **Category**: Security, Bug, Performance, Edge Case, Code Quality, Cross-Repo, or Cross-PR
* **Severity**: Critical, Important, or Minor
* **Short description**: One-line summary of the issue
* **Details**: Expanded explanation with a link to the specific file and line
* **Citations**: links to available sources for learned guidance. See [Citations in findings](#citations-in-findings).

### Citations in findings

Citations make team-specific review advice traceable. When a finding relies on learned guidance, its explanation can link to the instruction or earlier conversation behind that guidance.

The link appears within the finding, alongside the reasoning about the changed code. See [Knowledge source citations](/features/knowledge#source-citations) for how sources are retained and when a citation becomes a link.

<a id="review-coverage" />

### Verification

**Verification** follows Code Review and collects recorded outcomes, including linked issue objectives and rule results. It can appear without a code review. Covered objectives and checked expectations describe assessments against code, without claiming that runtime tests ran.

The header keeps one compact badge per feature, such as `Objectives 5/7`, `Rules 3/4 met` and `Repos 1 inspected`. Knowledge shows check and lens counts. The rule ratio excludes skipped checks and recorded actions.

The section opens for unmet requirements. A knowledge-backed finding opens it while that finding remains open in the current review. Settled outcomes collapse, even when Code Review still requests changes.

| Row | What it reports |
| - | - |
| Functional validation | Active objective counts, linked issues and objective names. |
| Rules | Check outcomes and recorded actions, with successful names visible in normal mode. |
| Auto-approval | Approved, Withheld or Not evaluated. |
| Knowledge | Expectations explicitly met and retained finding citations, with finding links. |
| Cross-repo | Recorded inspections and open impacts, or selected repositories when inspection status is unknown. |

Each feature has its own collapsed section and outcome badges. Open a feature to read up to five successful names. Unmet requirements stay visible without another toggle. `gitar display:verbose` adds remaining names and supporting evidence. Platforms without collapsible HTML show the same results as headings and compact rows.

<ThemeImage src="/assets/images/verification-reference-light.png" alt="Code Review still requests changes while Verification shows four covered objectives after opening its feature section" />

The [risk label](/features/code-review/risk-triage#where-risk-appears) appears separately in expanded Code Review, since risk describes the whole change rather than which checks ran.

## Providing Feedback

Feedback controls how Gitar handles findings on the current PR:

* Reply to a finding with an explanation. A confirmed fix resolves it. An invalid finding is dismissed. A decision to leave it unfixed closes it without counting it as fixed. On GitLab, replies to inline findings need no `gitar` prefix.
* **Reply `gitar fix`**: Every inline finding includes a "Reply `gitar fix` to apply this suggestion" footer. One reply and Gitar pushes the fix.
* **One-click apply**: On GitHub, check the box next to a suggested fix to apply it. On GitLab, react with the checkmark emoji. Gitar commits the fix to your branch. When a finding has multiple fixes, each one is numbered.
* Resolving a finding thread on GitHub closes it without marking it fixed or invalid. Unresolving that thread reopens it. On GitLab, a thumbs-down reaction dismisses a finding.
* **Stale findings**: When code is deleted or rewritten between review iterations, Gitar automatically resolves findings that pointed at the removed code.
* **Ambiguous replies**: If your reply is unclear, Gitar asks a follow-up question instead of guessing.

Your feedback persists across review iterations. Gitar won't re-report issues you've already dismissed.

With [Knowledge](/features/knowledge) enabled, explanations in review comments can also teach Gitar conventions for future PRs.

## Merge Blocking

Gitar can block PR merges based on its code review verdict severity. Configure a threshold in your [organization settings](/configuration/settings), and Gitar submits a blocking review on the PR when the verdict meets or exceeds it. See [Block Merge](/features/code-review/block-merge) for details.

## Auto-Approve

Gitar can automatically approve PRs after a clean review based on criteria you define. See [Auto-Approve](/features/code-review/auto-approve) for details.

## Auto-Merge

After auto-approve, Gitar can arm your platform's native auto-merge so the PR merges once all other checks pass. See [Auto-Merge](/features/code-review/auto-merge) for details.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.