Reviews your code the way your team would.
Write down how your team builds and point it at the docs you rely on. Auditor reviews every pull request, hands you fixes you can commit, and does the work when you mention it.
redirect() works by throwing, and the catch right after it swallows it, so a paid order stays on the checkout page.- redirect(`/orders/${order.id}`); } catch (err) { return { error: "Payment failed" }; }+ redirect(`/orders/${order.id}`);
Your rules first. Then a hunt for real bugs.
Every review checks the change against the Markdown rules in .rules/, then runs bug-finding passes: logic, security, data and concurrency, API contracts. A verifier drops anything it can’t confirm, so what gets posted is worth reading.
### API-PAGINATE-LISTS
severity: medium
applies: src/routes/**
List endpoints take a cursor and return at most 100 rows.
Never return a whole table.API-PAGINATE-LISTS in .rules/api.mdRules your agents read too
The same Markdown your team and coding agents follow. AGENTS.md, CLAUDE.md and Cursor rules count as well.
Knows the docs you build on
Add any documentation site. It’s distilled into short facts and quoted when a change touches them.
Settings in the repository
Review settings live next to the code, read from the default branch, so a pull request can’t loosen its own review.
Push back once
Reply that a pattern is intentional and it’s remembered for that directory.
Every finding has a page. Hand it to your agent.
The Fix link under a comment opens a page with the finding, the code and a prompt. Give it to Cursor, Claude Code or Codex in one step, or to Auditor, which fixes it on the pull request. Anyone with the link can read it; the repository stays private.
claude "$(curl -fsSL https://inferencebureau.com/f/k7m3q9/prompt)"No checkout yet? gh pr checkout 1204 gets one.Merge checks, written like you’d say them.
Write what must be true before a pull request merges. Auditor judges each one on every push and reports on a check of its own, so branch protection can block the merge. A pull request from a fork can’t talk its way past them.
Mention @auditor. It does the work.
On a pull request or an issue, in GitHub or Linear. Every command runs as inference on your Auditor key, inside your budgets.
Ask it anything
Questions about the change, the codebase or a finding. It reads the pull request, its diff and the conversation, searches the repository at the pull request’s head, and cites the files it relies on. Answers never change code.
Tests for what changed
Writes unit tests for what the pull request adds or changes and runs them in a sandbox, fixing them from their failures. Passing tests come as a pull request into your branch, or a commit onto it. It never touches the code under test.
Conflicts, resolved
Merges the base branch in and settles the conflicts so both changes survive, as a real merge commit on your branch, with each file’s resolution explained. Anything that needs your decision stops it, and the reply says which files.
From issue to plan to pull request
On an issue, it reads the issue, its comments and the code and writes a plan. Push back on it, then say go ahead or @auditor implement, and it opens a pull request that fixes the issue.
In Linear too
Mention Auditor on a Linear issue, or assign it one, and the same Issue assistant answers, plans it, or makes the change and opens a pull request that fixes the issue.
Put the reviewer on a schedule. Watch what it does.
Automations run on a schedule, a pull request, a push, a failed check, an issue or a webhook. Each has a permission level and its own budget.
Find out whether it’s a real break or a flake, and open a fix if it’s real
Propose$0.50 / runRead last week’s merged pull requests and post what changed to Slack
Read$0.20 / runFind where the bug likely lives and comment on the issue with a plan
Read$0.30 / runTurn an error report into an issue with the likely cause
Read$0.25 / runKinds of finding your team rarely acts on stop being posted. Push back once on a pattern and it’s remembered for that directory.
Reviews of a theme check what a pull request removes or renames against the content merchants keep on the store, before a page loses its settings.
Theme checksNo seats. Pay for the work.
Reviews, commands and automation runs bill as model requests on your Auditor key, from your prepaid balance. Set a monthly cap and a cap per pull request. A small pull request usually costs a fraction of a cent.
First review on your next pull request.
- 01
Install the GitHub App
From Team → Auditor, pick the repositories and turn them on. Reviews start on the next pull request.
- 02
Add .rules/ if you like
Without rules it reviews with built-in knowledge. With them, findings name your rules.
- 03
Open a pull request
Findings land as comments, with fixes you can commit.