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
Walkthrough comment
A top-level review summary that explains what changed, what Qodex checked, and whether findings were raised.
Inline findings
Comments attached to specific changed lines, with severity, category, confidence, and suggested fixes when safe.
Preview checks
Safe GET requests against a PR preview deployment to confirm whether a finding is reproducible.
Check Run
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, or supported Qodex mention 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.
Configure a repo in Qodex
Open Settings > PR review, then select the linked repository. If a monorepo is linked by folder, choose the specific folder entry: review settings and review context are kept separately for each linked folder. The Pull request tab lets you turn 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. 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.
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
How a review fires
Follow the sequence from GitHub event to posted review.
Install the GitHub App
Set up access so Qodex can see repos and review PRs.
Connect GitLab
Link GitLab.com projects for merge-request review.
Limits and caveats
Understand diff caps, confidence filters, skipped PRs, and probe limits.
Troubleshooting
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: minorand drops findings belowconfidence: 0.7. - Docs-only, generated-file, or no-op diffs may produce a clean review or be skipped by repo policy.