Pull request reviews
Reading a review
Summary comments, inline findings, severities, categories and what each line of a finding means.
A review has three parts: inline comments on the changed lines, one summary comment, and the check result.
Inline comments#
Each finding is posted on the lines it’s about. It reads like this:
Inline comment
Security | 🔴 Critical **Order lookup builds SQL from the customer's email** findOrdersByCustomer pastes customerEmail straight into the query string. **When it breaks:** an email of ' OR '1'='1 returns every customer's orders. **Suggested fix:** pass the email as a parameter ($1) instead of interpolating it. ```suggestion `SELECT ... WHERE c.email = $1`, [customerEmail], ``` 92% confidence · 💬 Reply here and Audit Bench Ai will recheck the code · 👀 to acknowledge · 👍/👎 teaches it what your team wants
- The header gives the category and severity.
- The title says what’s wrong in plain language, then a short description.
- Why it happens (when useful) explains the root cause.
- When it breaks gives the concrete input or sequence of events that triggers it.
- Tests says whether existing tests cover the behavior, when it matters.
- Suggested fix, with a one-click GitHub suggestion when the fix exactly replaces the commented lines, or an example patch otherwise.
- The footer shows how confident the reviewer is and how to respond.
If a finding comes back after being fixed, it’s marked ♻️ reappeared; if its lines changed but the problem is still there, 🔁 still present.
Severities#
| Severity | Meaning | Effect on the check |
|---|---|---|
| 🔴 Critical | Exploitable, data-losing or crashing in normal use | Fails |
| 🟠 High | Serious bug or risk that will bite in realistic conditions | Fails if it’s a Security finding; otherwise neutral |
| 🟡 Medium | A real problem with limited impact, or an edge case | Neutral |
| 🔵 Low | Minor issue worth fixing when convenient | None |
| 💡 Suggestion | Optional improvement; listed in the summary, never posted inline | None |
Severity and confidence are separate
Severity is how bad it would be; confidence is how sure the reviewer is that it’s real. A critical claim below 0.6 confidence is posted as medium, so a guess can’t block your merge. You can tune both thresholds in Rules and strictness.
Categories#
| Category | Covers |
|---|---|
| Security | Injection, auth and access control, secrets, unsafe deserialization, XSS |
| Logic | Wrong results, off-by-one errors, inverted conditions, unhandled cases |
| Reliability | Missing error handling, retries, timeouts, crashes on bad input |
| Data Integrity | Lost or duplicated writes, missing transactions, money in floats |
| Concurrency | Races, check-then-act, double processing |
| Resource Management | Leaks, unbounded memory, connections left open |
| Performance | N+1 queries, needless work in hot paths |
| API Design | Breaking changes to callers, confusing or unsafe interfaces |
| Semantic Accuracy | Names, comments or docs that say something different from what the code does |
| Testing | Tests that don’t test what they claim, missing coverage for risky behavior |
| Architecture | Layering and coupling problems (capped at medium) |
| Maintainability | Deep nesting, very complex functions, duplication (capped at medium) |
The summary comment#
One comment per review, updated as you push. From the top:
- Actionable comments posted, and how many findings were not repeated because they’re still open from an earlier review or your team dismissed them.
- Merge readiness: ✅ Ready, 🟡 Ready with notes or ⛔ Not ready, with lists of what to fix before merging and what’s worth a look.
- Merge risk and pre-merge checks: whether the title and description explain the change, whether an issue is linked, and whether the scope is focused.
- Collapsible sections: a walkthrough of each file, review info (commit, verdict, counts), optional suggestions, and a prompt to fix you can paste into an AI coding agent.
Verdict#
- ⛔ Do not ship: at least one critical finding.
- ⚠️ Needs work: high or medium findings.
- ✅ Pass: nothing above low.
Merge readiness also counts things outside the code: a draft, merge conflicts, failing CI checks and likely secrets all make a pull request ⛔ Not ready.
The full report#
The Open full report link in the summary opens the review in the web app, with every finding, the local check results and the token cost.