> ## 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.
# Anatomy of a Qodo Code Review
> Qodo surfaces code review feedback directly inside your pull requests in a way that is actionable, focused, and easy to resolve.
Qodo's code review surfaces feedback directly inside your pull requests, structured incrementally from context to individual findings, so you can read, prioritize, and act on it without wading through noise. Each finding focuses on what requires attention and why, with clear links back to the relevant code.
This page is a reference for that structure: each section below corresponds to a part of the pull request, in the order it appears.
New to Qodo? It's recommended to read this reference page top to bottom. Already reviewing a pull request? Skip ahead to [Unpack a code review finding](#unpack-a-code-review-finding).
## Pull request summary
Before presenting individual issues, Qodo provides context to help you understand *what changed* and *why it matters*. For more information about how this context is generated and configured, see [Generate a PR summary](/code-review/pr-summary).
This includes the following sections:
Qodo adds an AI-generated summary of the pull request's intent and impact.
* By default, the summary is posted as a standalone comment and your original pull request description stays unchanged.
* You can also configure Qodo to merge the summary into the native pull request description.
This helps reviewers align quickly on the purpose of the pull request.
Qodo tags each pull request and estimates how long the review will take, so reviewers can prioritize before opening a single file. Tags include: Bug fix, Tests, Enhancement, Documentation, and Configuration changes.
Qodo breaks down the change in detail:
* **Description:** A plain-language breakdown of what changed and why.
* **Diagram:** An architecture diagram showing the flow and connections introduced by the change.
* **High-Level Assessment:** Suggestions and alternatives for the author and reviewer to consider before or during review.
Qodo provides a file-level overview of the pull request.
For each modified file, you can see:
* The file path
* The type of change (for example, Bug Fix or Enhancement)
* Lines added and removed
This helps reviewers understand the scope of the change set before examining individual findings.
## Code review findings overview
After providing context, Qodo presents a findings overview covering category counts, the context behind the review, and each finding's quality impact and severity.
This includes the following sections:
Findings are grouped by category, with counts for each type.
| Category | What it means |
| - | - |
| **๐ Bugs** | Issues that may cause incorrect behavior or failures. |
| **๐ Rule violations** | Violations of organizational or repository rules. |
| **๐ Requirement gaps** | Missing or unmet business or ticket requirements. |
| **๐ Cross-repo conflicts** Beta | Breaking changes detected across repository boundaries. See [Cross-repository code review](/governance/cross-repo-code-review). |
| **๐ Skill insights** Beta | Guidance or violations surfaced from a repository's skills. See [Manage skills across repositories](/governance/manage-skills-across-repositories). |
This overview gives you an immediate sense of the review's focus and severity.
When a review draws on additional context, such as [rules](/governance/rule-enforcement), [skills](/governance/manage-skills-across-repositories), or [cross-repo context](/governance/cross-repo-code-review), Qodo displays a **Context sources** section listing exactly what was applied.
The section also carries the review's routing summary: a line such as *"2 issues published inline ยท 3 in summary"* showing at a glance how the findings were split between inline comments and the summary. Routing is controlled by the [Comments settings](/configuration/display#comments).
When [web search](/code-review/use-qodo-in-prs/third-party-dependencies-context) contributes to a finding, the Context sources section also lists the external sources the agent referenced, such as official documentation, release notes, or specifications.
When cross-repo context contributes to a [cross-repository conflict](/code-review/view-cross-repo-conflicts-in-findings) finding, the Context sources section also links to the relationship behind it. Each explored repository has a **View relationship** link. Click it to open that relationship in the **Relationships** tab. Access follows your organization's portal permissions. For more information, see [View cross-repository conflicts](/code-review/view-cross-repo-conflicts-in-findings).
Disable the **Show context** setting to exclude this section from the code review, for example if it adds noise for your own tooling that parses Qodo's PR comments. For more information, see [Configure Qodo using the portal](/configuration/display#comment-parts).
In addition to categories, each finding includes a quality impact label. This label indicates which quality dimension is affected by the issue.
Common labels include:
| Label | What it means |
| - | - |
| **Correctness** | Issues that may cause incorrect behavior or wrong results. |
| **Security** | Issues that could expose vulnerabilities or sensitive data. |
| **Reliability** | Issues that may affect stability, error handling, or fault tolerance. |
| **Performance** | Issues that impact efficiency, latency, or resource usage. |
| **Observability** | Issues that affect logging, metrics, or system visibility. |
These labels provide quick semantic context, helping you understand *what kind of quality is impacted* before diving into the full issue details.
Findings are grouped by severity, making it clear what needs attention first.
| Severity | What it means |
| - | - |
| **High** | High-priority or blocking issues that should be addressed before merging, such as security or compliance violations, sensitive data exposure, or critical correctness issues. |
| **Medium** | Non-blocking issues that improve code quality, maintainability, or consistency with defined standards. |
| **Low** | Lower-impact or informational findings that provide context or optional guidance. |
**High, Medium, and Low** are the default severity labels. You can rename them using the **Severity terminology** setting. For more information, see [Configure Qodo using the portal](/configuration/display#groups).
This prioritization helps you focus on what matters most without losing visibility into the full set of findings.
As you push new commits, Qodo marks the findings that no longer need action. A resolved finding is struck through and shows only its status, which keeps the focus on the open findings. Each resolved finding has one of these statuses:
* โ Resolved: A later commit fixed the issue.
* โ Dismissed: The finding was dismissed without a fix and no longer needs action.
* โ Outdated: The code the finding referred to was removed or rewritten. The finding no longer applies.
By default, resolved findings stay in their group. You can move them to a separate **Resolved findings** section after the open findings, or hide them entirely. For more information, see [Track resolved findings](/code-review/track-resolved-findings).
## Unpack a code review finding
Each finding can be expanded to reveal full details. You can access findings:
* From the prioritized summary list
* Inline, directly in the **Files changed** view
Regardless of how you access it, each finding presents the same structured information.
Click each tab below to see the different elements of a finding:
A clear, human-readable explanation of the issue and its potential impact.
* A snippet showing where the issue occurs
* Direct links to the relevant lines in the pull request
Beta
GitHub
GitLab
Entries are generated automatically based on [PR history indexing](/core-concepts/pr-history).
The **Relevance** section highlights related pull requests with similar findings from past reviews. This provides historical context by linking to previous pull requests where a similar issue was discussed, accepted, or rejected.
Each entry includes:
* A relevance classification indicating whether the finding has high, medium, or low relevance based on how similar findings were handled in past pull requests:
* โญโญโญ **High**: Similar findings were typically accepted/fixed.
* โญโญ **Medium**: Mixed or inconclusive history.
* โญ **Low**: Similar findings were typically ignored.
* A brief explanation of the historical pattern
* Links to relevant past pull requests
* An indicator that the insight was generated from similar findings
For more information about how this classification works, see [Prioritize findings using Relevance](/code-review/relevance).
Context explaining *why* the issue was flagged, such as:
* The specific rule involved, linked to that rule in the Qodo portal
* For cross-repo conflicts, the repository relationship behind the finding, linked to that relationship in the Qodo portal
* Linked requirements or tickets (when applicable)
Click a rule link to open the rule's side panel on the **Rules** page, where you can check what the rule requires. Admins can also edit the rule there. Rules that have a standard ID are shown by ID without a link.
Click a relationship link, labeled with the two repositories such as `web-client -> api-server`, to open that relationship on the Relationships tab. For more information, see [View cross-repository conflicts](/code-review/view-cross-repo-conflicts-in-findings#cross-repository-conflict-details).
On Gerrit, the rule name in an inline finding comment also links to the rule.
This transparency makes it easier to trust and validate the feedback.
For issues that can be fixed programmatically, Qodo provides an **agent prompt**. You can copy the prompt and use it in an AI coding tool to apply the suggested fix with full context, helping you move from feedback to resolution faster.
GitHub
GitLab
For small, inline findings in a single file, Qodo attaches a commit-ready fix directly to the comment. You can apply it without switching to your local environment.
* Click **Apply Suggestion** to commit the fix immediately.
* Click **Add suggestion to batch** to group multiple fixes into a single commit.
For more information, see [Commit code fixes directly in the pull request](/code-review/commitable-code-suggestions).
Each finding includes two links that open it in the Qodo portal:
* **Dismiss**: Opens the finding directly in the portal's dismiss reason picker.
* **View**: Opens the finding in the portal without dismissing it, showing the same detail panel described throughout this reference.
Both links route you from the pull request to the Qodo portal, directly to this finding. If you're not already signed in, you're prompted to sign in first.
For more information, see [Dismiss a finding](/code-review/dismiss-a-finding).
Findings from all pull requests are also tracked centrally in the Qodo portal. For more information about filtering and monitoring findings across all repositories, see [Monitor organization-wide pull request findings](/governance/view-all-findings-in-organization).
## Previous reviews (formerly Audit trail)
Qodo keeps a collapsible **Previous reviews** section in the comment, showing the history of past review runs on the pull request. It renders like the comment's other collapsible parts (Context sources, Tip of the day) and sits between the daily tip and the footer:
* A **Review updated until commit** line links to the commit the current review reflects.
* Each earlier commit has its own collapsible **Results up to commit** entry.
* A review-mode badge, for example ๐ Fast or โ๏ธ Balanced, shows which mode produced the review.
* Expanding an entry surfaces the full set of findings from that earlier review run. Findings that were later resolved appear struck through with a resolved mark, reflecting the current state of every finding.
This helps reviewers see how the review evolved as new commits were pushed. Disable the **Show previous reviews** setting, under **Comment parts** in the portal's **Display** tab, to hide this section from the review comment. For more information, see [Configure Qodo using the portal](/configuration/display#comment-parts).
## Native pull request labels
Beyond the review comment itself, Qodo can publish select signals as native labels directly in your Git provider's pull request interface, for example in the Labels sidebar or the pull request list.
* **Review time estimate**: See [Generate a PR summary](/code-review/pr-summary#publish-the-review-time-estimate-as-a-native-label-or-tag).
* **Blast radius**: See [Assess code change risk using blast radius](/code-review/assess-risk-with-blast-radius).
## Related resources
* [Prioritize findings using Relevance](/code-review/relevance): See how likely each finding is to matter, based on your team's history.
* [Assess code change risk using blast radius](/code-review/assess-risk-with-blast-radius): Triage pull requests by the risk of the change.
* [Dismiss a code review finding](/code-review/dismiss-a-finding): Close a finding without fixing it and record why.
* [Customize the code review experience](/configuration): What you can configure, and where to configure it.
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.