> ## 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. # How Gitar Works > How Gitar combines code structure, team knowledge, and connected sources to review changes and validate fixes Gitar reviews changes in their engineering context. It combines the diff with code structure and team knowledge, then investigates the questions that need more evidence. ## What a review covers A Gitar review checks code behavior and connects the change to the requirements and systems around it. | Review concern | What Gitar examines | Result | | - | - | - | | [Code defects](/features/code-review) | Changed behavior and the surrounding implementation. | Inline findings with a proposed fix. | | [Risk triage](/features/code-review/risk-triage) | The impact of the whole PR under team-defined risk policy. | A Low, Medium, or High risk label. | | [Functional validation](/features/functional-validation) | Each objective in the issue the PR claims to implement. | Completion status for each objective, refreshed across pushes. | | [Cross-Repo Analysis](/features/cross-repo-analysis) | Contracts and dependencies shared with other repositories. | Findings that name the affected repository and what needs changing. | | [Cross-PR Analysis](/features/cross-pr-analysis) | Related open PRs whose changes interact. | Findings that explain the mismatch and link to the related PR. | | [Knowledge](/features/knowledge) | Relevant team guidance and lessons from earlier reviews. | Review advice grounded in the codebase's conventions. | | [CI Failure Analysis](/features/ci-failure-analysis) | Failing build and test output in the context of the change. | A root-cause explanation and a suggested or applied fix. | The [Review coverage](/features/code-review#review-coverage) section on the PR shows outcomes for functional validation and automation. Feature availability follows the [organization's plan](/account-billing/plans). ## Code structure informs the review Gitar uses structural outlines to locate functions and types, then reads the implementation when a change needs more context. Function and type outlines show where a change sits in a larger file. Gitar reads related code and searches for callers when a change raises a question about behavior elsewhere. For example, changing a shared helper can require checking its callers and tests even when those files are outside the diff. Structural context helps locate the code, and Gitar examines the implementation to assess the effect. ## What context Gitar uses Gitar selects context for the task and reads further when a finding needs supporting evidence. | Context | How it helps | | - | - | | PR diff and metadata | Establish what changed and what the author intends. | | Changed files and structural outlines | Place edits inside the surrounding implementation. | | Related files and tests | Check callers and behavior outside the changed lines. | | Repository and organization instructions | Apply the team's [review guidance](/configuration/repository-config#custom-review-instructions). | | Learned conventions and reviewer feedback | Apply relevant [knowledge from earlier work](/features/knowledge). | | Linked issues | Check [implementation against individual requirements](/features/functional-validation). | | Other repositories | Check [cross-repository impacts](/features/cross-repo-analysis), including across code hosts. | | Connected documentation and tools | Consult [Confluence and other knowledge sources](/features/knowledge#connected-knowledge-sources). | | Web documentation | Verify dependency behavior against [web references](/features/knowledge#web-knowledge). | | CI results | Diagnose failing jobs using their logs and the code change. | A [configuration repository](/configuration/configuration-repository) shares guidance across the organization. [Skills](/integrations/skills) provide reusable procedures that Gitar loads when a rule or PR comment calls them. ## Review across repositories Cross-Repo Analysis supports unlimited linked repositories and discovers relevant connections across the organization. A GitHub service and its GitLab client can be checked together. Gitar uses repository summaries to identify likely connections, then reads relevant files to verify the impact. Findings name the affected repository and explain which side needs a fix. See [Cross-Repo Analysis](/features/cross-repo-analysis) for coverage and visibility rules. ## Evidence in the review Findings land on the changed lines they concern and explain the behavior behind the issue. [Source citations](/features/knowledge#source-citations) connect learned guidance to its origin, so a team convention can be checked against the instruction or conversation that established it. The [Code Review section](/features/code-review#review-output) collects findings and the verdict in the existing PR dashboard comment. Later pushes refresh that comment and revisit earlier findings. ## From findings to validated changes Gitar can apply a suggested fix when requested, or push fixes automatically under [auto-apply](/commands). Subsequent CI results provide evidence about whether the change builds and passes the configured checks. [Functional validation](/features/functional-validation) separately tracks whether the implementation addresses the linked issue's objectives. Passing CI and covering the requested behavior answer different questions. If a Gitar fix introduces a CI failure, [automatic recovery](/features/ci-failure-analysis#recovery-after-a-gitar-fix) can continue the repair without another developer request. Findings and risk also inform configured [approval](/features/code-review/auto-approve) and [merge criteria](/features/code-review/auto-merge). ## Data access and controls Repository access follows the organization's connected code hosts. Custom integrations use the credentials and allowed tools configured for each connection. [Cross-repository visibility](/features/cross-repo-analysis#repository-visibility) controls which repositories can contribute context to a review. Gitar runs work in isolated environments and uses repository caches to support repeated reads. Processing and retention details belong to [Security](/administration/security#data-retention--privacy). Enterprise organizations can choose their own model account through [Bring Your Own Model](/administration/bring-your-own-model). Fixes land as additional commits. Gitar merges only when [Auto-Merge](/features/code-review/auto-merge) is enabled and its criteria and platform checks allow it. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.