👁️ Code Review Bot for Pull Requests

The problem

Linters catch formatting. Humans catch design. But there's a huge gap — bugs that linters miss and humans overlook at 5pm on Friday. Getting humans to review every PR doesn't scale; getting them to review thoroughly never scales. You want a second set of eyes that runs on every PR and catches the obvious-in-retrospect issues.

The outcome

Every PR gets an automated review within 60 seconds of opening. Comments are specific and linked to line numbers. It catches: off-by-one errors, missing null checks, unhandled error paths, tests that exercise the happy path but not the failure path. Humans still review — but they focus on design, not boilerplate.

Why IronClaw

IronClaw runs tools in a WASM sandbox where each tool can reach only the hosts in its capabilities.json, and credentials are injected by a proxy so the tool never sees them. That documented design (written for 0.29.x; the 1.x extension host was rebuilt, so check the current docs) limits what a review tool can do with read access to your code.

Alternatives worth considering

• OpenClaw — Faster to set up with lighter isolation by default: fine for solo developers or open-source projects, as long as you follow its hardening guide
• Claude Cowork — Paste the diff, get review — no automation, but the quality is arguably better since you can add context

Setup steps

1. Step 1: Trigger the review when a PR opens

   Use your CI or a GitHub Action to call the agent when a pull request opens. Scope it to specific repos, with a dedicated service account that has read-only code access and permission to comment.

2. Step 2: Write the review prompt carefully

   Give the model a role: 'senior engineer doing PR review'. Tell it what to flag (bugs, security, missing tests) and what to ignore (style, formatting — that's the linter's job). Specificity matters — generic reviews are useless.

3. Step 3: Add a 'no opinions on design' rule

   Design debates should be human. The bot's value is catching what humans miss, not rehashing what humans will argue about. Explicitly forbid comments like 'consider refactoring this.'

4. Step 4: Batch the PR diff intelligently

   Large PRs will blow your context budget. Split by file, review each with a small, low-cost model, then use a stronger model only for the summary.

5. Step 5: Monitor the signal-to-noise ratio

   Track what % of bot comments devs mark as helpful. Aim for >60%. Below that, tune the prompt. Nobody reads a reviewer that cries wolf.

Example prompt

Review this PR diff as a senior engineer. Flag: logic bugs, missing null checks, unhandled errors, tests missing for non-happy paths. Skip: formatting, style, design opinions. Comment inline with line numbers. Keep each comment under 80 words.

Pitfalls to avoid

• Letting the bot block merges. Never. The bot advises; humans decide. A blocking bot becomes a rubber-stamp bot the day it hallucinates.
• Exposing source code to external APIs without approval. Check with security and legal. Proprietary code going to an API provider is a policy question. If policy forbids it, use a self-hosted model and confirm your agent supports it.
• Paying for the strongest model on every file. Cost can spiral on large PRs. Run a cheap model by default and escalate only when a file is flagged as complex.

Cost breakdown (monthly)

Cost: Model usage only. Model rates change often; check the model pricing table or the cost calculator for current figures.

Related guides

• IronClaw setup
• Skill allowlisting
• Security architecture
• Model API pricing