Deploy a review agent in YAML: it reacts on every head advance of a pull request, reviews only the commits it has not seen, and runs the suite before it comments. Any coding agent can write slop; yours is the one that catches it before merge.
The prompt, the model, the repositories it watches, and the spend caps are all yours, in one file in your repository. Tune what it flags and what it ignores the way you tune a linter, and ship the change as a pull request.
ellipsis: version: v1 kind: code_review name: Code review description: Review the new commits on every pull requestpull_requests: repositories: [splitshift-web, splitshift-api] for: users: true bots: falsereview: - name: correctness claude: model: claude-haiku-4-5-20251001 system: | Flag correctness bugs, unhandled edge cases, and breaking changes. Suggest the fix on the exact line.budget: run: 10.00Your prompts and your models, committed to the repo
The agent reviews only the commits it has not seen yet, anchored at the head it reviewed last. Authors get feedback on what they just pushed instead of the same comments on the same lines, so a long-running branch never turns into review noise.
Only the commits since the last review
The agent gets your repository on disk with the toolchain installed, so it can run the suite, reproduce the failure, and check the behavior it is worried about. A finding it verified is a finding worth reading.
# reviewing splitshift-api#512, push 2
$ pytest -k trade
14 passed
$ git diff HEAD~2 -- src/trade_engine.py
reads the actual change, runs the actual suite, then comments
Findings verified by running the tests
The review is a durable conversation that remembers the whole pull request. Push back on a finding, ask it to fix what it found, or tell it to use the staging database, and it picks up with its working tree intact. Merge closes the conversation.
marcus-lee
@ellipsis use the staging database, not prod
👀 · conversation woken, same working tree
ellipsis[bot]
Switched the fixtures to the staging database and re-ran the suite: 12 passed. Pushed the change to this branch.
One durable conversation per pull request
Ellipsis measures whether review comments changed the merged code, not just how many comments were posted.
Measured against the merged code, not comment count
See review volume over time, stacked by blocking, high, medium, low, and trivial findings.
Review volume over time, stacked by severity
For each severity, the share of posted comments that were acted on: the flagged issue resolved on the default branch after merge. Blocking and high findings should land far more often than nits, and they do.
Blocking findings land far more often than nits
Every comment is classified (logical bugs, security, performance, maintainability, testing, style, and more) so you can see whether Ellipsis is catching substance or just nits.
Bugs and security lead the mix, not style nits
The heatmap crosses every comment type with its severity. Darker cells mean more findings, so you can instantly see where the serious problems cluster: logical bugs skew high, style skews trivial.
Darker cells are where the serious findings cluster
Track where comments drop off: findings surfaced by the agent, those that pass the quality gate, the ones posted to GitHub, and finally the ones addressed after merge. A tight funnel means high signal and low noise.
Surfaced, gated, posted, addressed