Clud Bug.

Most reviews are a single fast pass — skill-aware and cited. On the Team tier, Clud Bug runs a two-pass cross-check: a second naturalist re-reads the first one’s findings against the diff, and a third — the arbiter — is called in only when the two disagree:

Three perspectives, one PR thread, citations all the way down. Compare tiers →

Most review tools can only point at one suspicious line, so those are the only bugs they catch. Clud Bug grounds every finding one of three ways — a line quoted from the diff, a reproduction it actually runs, or a named invariant the change breaks. The reproduction is the sharp end: a real bug often lives on no single changed line.

That reaches three classes a line-scanner walks past. Emergent — bad data flowing through individually-correct lines, like a shared default mutated across calls. Combinatorial — an invariant broken only by a constructed input, like a duplicate key on a collision. Cross-cutting — a cause in another file the diff merely exposes, like a date-only sort read from a module the change never touched.

The measurement. On a seeded corpus of 20 scenarios — 14 planted defects across those three classes plus 6 clean look-alikes as precision controls, each scored by three independent reviewers — the hardened recipe caught every bug and false-flagged none: 100% recall, 100% precision, every catch grounded by a reproduction the reviewer wrote and ran.

Every PR review gets a budget tailored to its diff. Clud Bug looks at the changed lines first — a one-file typo gets a quick pass; a thousand-line refactor gets the time it needs. The bot is told its own budget upfront and checks in with itself mid-review, so the summary at the bottom of your PR is always a finished thought, never a half-written sentence.

Why this matters. Stock PR-review tools pick a fixed turn count and hope. On small PRs they overspend; on large PRs they run out and leave you with an incomplete review. The budget-aware approach: tiny PR gets ~5 turns of attention, large PR gets ~25, very large gets ~40 — same Clud Bug, same quality bar.

Every finding lands with a one-line fix. Push the change, and on the next commit Clud Bug re-reads each thread it opened — comparing the code at the anchor before and after — and decides, thread by thread, whether the concern was actually addressed.

A thread that was addressed resolves itself and says so. One that was not stays open, noted that the re-review still applies — and if it was critical, the check flips to request-changes. When the verdict is uncertain on a critical finding, the thread stays open and escalates: a critical is never silently dismissed. What was genuinely fixed clears out; what still matters stays pinned.

Code review reads the diff; it never sees the page. When a repo carries design skills — a house style, a spacing scale, a set of elite-UI standards — Clud Bug can open an optional visual pass. On a pull request with a live preview, it renders each changed surface in light and dark, then critiques the screenshots against those skills, citing the element it sees and the standard it reads against.

It flags what is fine but not elite, not only what is broken. The pass stays off until a repo asks for it, and stays advisory until it is told to gate — the render runs only on an opted-in Team repo, only on a pull request, only when a design skill is installed.