Skip to main content

​
PR review

Qodex reviews pull requests on linked GitHub repos. When a PR opens or changes, Qodex reads the diff, looks for real bugs and security issues, posts a walkthrough comment, adds inline findings where it can, checks the preview deployment when available, and updates 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 pull_request webhook, or an @qodex review comment, starts the review. Qodex fetches the PR diff through the GitHub App, 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 GitHub review, records the findings, and completes the Check Run as neutral, success, or failure depending on the repo’s gate policy.

​
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.

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: 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.

​
On the roadmap

Slash commands @qodex resolve <id>, @qodex false-positive <id>, and @qodex wontfix <id> ship in M1c piece 4 alongside the learning loop. Resolved findings will train the per-project filter so the same noise stops recurring.

Install the GitHub App

Connect a repo

.qodex.yaml reference

Troubleshooting