> ## Documentation Index > Fetch the complete documentation index at: https://qodex.ai/docs/llms.txt > Use this file to discover all available pages before exploring further. # PR review > Qodex reviews linked GitHub pull requests and GitLab merge requests with summaries, inline findings, and preview checks. # PR review Qodex reviews pull requests on linked GitHub repos and merge requests on linked GitLab.com projects. When a change request opens or changes, Qodex reads the diff, looks for real bugs and security issues, posts a walkthrough comment, adds inline findings where it can, and checks the preview deployment when available. GitHub reviews also update a GitHub Check Run. ## What Qodex adds to a PR > [card] [Walkthrough comment](https://qodex.ai/docs/pr-review-walkthrough-anatomy.md) > > A top-level review summary that explains what changed, what Qodex checked, and whether findings were raised. > [card] [Inline findings](https://qodex.ai/docs/pr-review-inline-findings.md) > > Comments attached to specific changed lines, with severity, category, confidence, and suggested fixes when safe. > [card] [Preview checks](https://qodex.ai/docs/pr-review-verification-probes.md) > > Safe GET requests against a PR preview deployment to confirm whether a finding is reproducible. > [card] [Check Run](https://qodex.ai/docs/pr-review-check-run.md) > > A GitHub status check that is advisory by default and can be configured to block merges on verified findings. ## Review flow A GitHub pull-request webhook, GitLab merge-request webhook, supported Qodex mention, or the **Run review** button in Qodex starts the review. Qodex fetches the change-request diff through the linked source-control connection, reads `.qodex.yaml`, loads project context, and reviews the diff with a high-precision confidence floor. Findings below `0.7` confidence are dropped before they reach the PR. Repo rules such as severity thresholds and excluded paths are applied next. Findings on changed lines become inline comments. Findings outside the diff move into the walkthrough body so they are still visible. If the PR has a successful preview deployment, Qodex can run safe verification probes and attach request and response evidence. At the end, Qodex posts the review and records the findings. For GitHub, it also completes the Check Run as `neutral`, `success`, or `failure` depending on the repo's gate policy. ## Deeper review on larger PRs For larger or riskier pull requests, Qodex can spend extra review attention where it is most useful: real bugs, missing tests, risky behavior changes, and security issues. The goal is still the same: fewer low-value comments, more findings that explain a real risk. Repo settings and `.qodex.yaml` decide which paths, severities, and confidence levels should reach the PR. ## The PR review page In your project, open **Code > PR review** in the sidebar. The page has a **Repository** selector and a **Period** selector at the top, and three tabs: * **Overview**: what Qodex reviewed and found in the selected period. Tiles show pull requests reviewed, **Findings posted**, **Acted on** (resolved by the team or fixed on a later push), **Dismissed**, and **Time to first review** (the median wait from the PR being opened, pushed to, or someone asking for a review, to Qodex posting it). Below the tiles are the split between on-request and automatic reviews, reviews and findings over time, findings by category and by severity, and a breakdown by author. * **Pull requests**: every tracked PR with its state, author, review status, and finding counts. Filter by **Status** or **Author**, or search by title, repo, branch, or author. The toolbar shows how many pull requests the month has used against the project's plan. Click a row to open its review record. * **Settings**: review settings for the repository chosen in the **Repository** selector. For a project whose linked repos are all on GitLab, the page says merge requests instead of pull requests. The **Period** selector offers calendar months (UTC) and **All time**. The Overview also offers **Last 3 months** and **Last 12 months**. ### A PR's review record Click a pull request to open its record. The header links to the PR on GitHub or GitLab and has a **Run review** button (**Review again** after the first review) for open PRs. Below it are tiles for findings, security findings, open findings, and reviews, then the review **Summary**, the **Findings** (filter by **Open**, **Acted on**, or **Dismissed**), and the **Review history**, which shows what started each review, for example a push or a request by a named person, and why a review was skipped. Answers Qodex gave to questions asked on the PR appear under **Questions and answers**. After a review finishes, **Run review** waits two minutes before it can run another one. The button shows the time left. When the pull request has used every review its plan includes, the button is disabled and says why. ## Configure a repo in Qodex Open the **Settings** tab on the PR review page and pick the repository in the **Repository** selector. You can also open **Settings > PR review** and select the repository there. If a monorepo is linked by folder, the selector lists each folder as its own entry, for example `acme/shop (backend)`: review settings and review context are kept separately for each linked folder. The **Pull request** tab lets you turn **Automatic reviews** on or off, choose the minimum severity, place lower-severity style and convention notes in the walkthrough instead of inline threads, configure merge blocking, exclude paths or rules, and limit reviews to particular authors or base branches. With **Automatic reviews** off, opening or pushing to a PR no longer starts a review, but `@qodex-ai review` and the **Run review** button still do. This makes a repository review-on-request. Every review still counts against the plan. Use **Commands** to see every available PR command. The approval command is off by default; a maintainer must enable it here before `@qodex-ai approve` can submit a GitHub approval. **Review context** stores owner-written review guidance and the lessons Qodex has learned from prior PR discussions. `.qodex.yaml` in the repository takes precedence over the overlapping pull-request settings at review time. ## Plan usage emails When a project's plan includes a set number of pull requests a month, project members get an email when 80% of them are used and another when they are all used. Each email is sent at most once a month and links to the PR review page. See [Limits and caveats](https://qodex.ai/docs/pr-review-limits-caveats.md) for how plan limits work. ## Project-specific learning Qodex can use resolved findings and reviewer feedback from earlier PRs as project-specific context for future reviews. This helps the reviewer avoid repeating issues the team has already handled and keep useful project rules close to the repo. When there is no learned context yet, the PR review surface explains that clearly so users know the feature is empty because the project has not built review history. For monorepos, link the same repo by project directory so each app or service can keep its own review context. ## Where to go next > [card] [How a review fires](https://qodex.ai/docs/pr-review-how-it-fires.md) > > Follow the sequence from GitHub event to posted review. > [card] [Install the GitHub App](https://qodex.ai/docs/pr-review-install-github-app.md) > > Set up access so Qodex can see repos and review PRs. > [card] [Connect GitLab](https://qodex.ai/docs/integrations-gitlab.md) > > Link GitLab.com projects for merge-request review. > [card] [Limits and caveats](https://qodex.ai/docs/pr-review-limits-caveats.md) > > Understand diff caps, confidence filters, skipped PRs, and probe limits. > [card] [Troubleshooting](https://qodex.ai/docs/pr-review-troubleshooting.md) > > Fix skipped reviews, neutral checks, uncertain anchors, and opt-outs. ## When to use it * Use PR review when you want one reviewer per repo that focuses on real bugs, security issues, and risky behavior changes. * Use it when you ship several PRs a day and want review status next to CI. * Use it when linting already catches style problems and you want a reviewer that can also test a preview deployment. ## When not to use it * Do not expect Qodex to be a nitpicker. It defaults to `severity_threshold: minor` and drops findings below `confidence: 0.7`. * Docs-only, generated-file, or no-op diffs may produce a clean review or be skipped by repo policy. ## Related > [card] [Install the GitHub App](https://qodex.ai/docs/pr-review-install-github-app.md) > [card] [Connect a repo](https://qodex.ai/docs/pr-review-connect-repo.md) > [card] [.qodex.yaml reference](https://qodex.ai/docs/qodex-yaml-reference.md) > [card] [Troubleshooting](https://qodex.ai/docs/pr-review-troubleshooting.md) This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.