Code review

Ellipsis reviews pull requests as commits land. Each push gets a review of only the new commits, and findings arrive as inline comments on the lines they concern.

What code review does

One organization-wide toggle turns it on. Every pull request in the organization is then reviewed by the built-in pipeline, on the open and on every push after it. Three properties keep the result worth reading:

• New commits only. A review covers the commits since the last review, never the whole pull request again, and it never re-comments a line it already covered.
• Only defects it confirmed. The reviewer files a finding only when it can point at the line that is wrong and name the input or state that breaks it. A review that finds nothing posts a one-line clean summary rather than invented nitpicks.
• Comments anchor to the reviewed commit, so they stay attached to the right lines as the pull request grows, and GitHub collapses them as outdated when a later push changes those lines.

Ellipsis posts one comment-only review per run, authored by the Ellipsis bot. It never approves, requests changes, pushes commits, or merges, so it cannot satisfy a required-review rule or block a merge.

How a review runs

A review is a pipeline of stages. Each stage agent runs in its own sandbox with the repository checked out at the reviewed commit, so it judges the change against the surrounding code, not the diff alone.

push lands on api-repo#519
        │
        ▼
  pre_review     context for the reviewers, or cancel a review the
                 range does not need      (empty by default)
        │
        ▼
  description    rewrites the summary block on the PR body; applied
                 the moment it settles, before the reviewers start
        │
        ▼
  review         each reviewer reads the new commits in parallel
                   bugs: 5 findings              (the default one)
        │
        ▼
  filter         a gatekeeper you declared judges each finding
                 against the code: 5 -> 2        (empty by default)
        │
        ▼
  posted review  one PR review anchored to the reviewed commit

Out of the box the pipeline is two agents: a Haiku pr-description agent that keeps the pull request description summarized, and one Opus reviewer, bugs, briefed to find defects across every category at once (logic errors, unhandled edge cases, error handling, concurrency, security, regressions callers depend on, data and deploy hazards). Nothing sits between the reviewer and your pull request unless you declare a gatekeeper.

One review per pull request, anchored at head. The first review of a pull request covers everything on it. Every review after that covers only the commits since the last review that posted: Ellipsis remembers the last reviewed commit per pull request and reads from there to the current head. A review that fails does not count as coverage, so nothing is silently skipped. See Which PRs get reviewed.

Enable it

You need the Ellipsis GitHub App installed; nothing else.

1. Open the Reviews page in the dashboard and select the Settings tab.
2. Turn on Review pull requests. In an organization, only administrators can change it.

The switch is organization-wide and off by default. No configuration file is needed: the toggle alone reviews every pull request in the organization, and YAML can scope or customize review but never enables it.

Your first review

1. Open a pull request in api-repo, or push a commit to an open one. Either triggers a review. Bot pull requests are reviewed too, apart from dependabot[bot] and renovate[bot]: a dependency bump is exactly the change nobody reads closely, but reviewing every batch those two open would dominate your spend.
2. Watch the pull request. An eyes reaction appears while the review runs. When it finishes, one review posts with inline comments, anchored to the commit it reviewed. A clean change gets a one-line summary.
3. Open the Reviews page in the dashboard. The review is listed with its findings, cost, and the commits it covered.

Push twice more over the afternoon and the pipeline runs twice more, each time reading only what that push added.

Tune it

Everything past the toggle lives in one optional file, code_review.yaml. Where you commit it decides what it governs: at the root of your .ellipsis repository it governs the whole organization, at the root of any other repository it governs that repository.

• Which PRs get reviewed: where the file lives, incremental scope, the filters, when a push produces no review, and reviewing on demand with the API or agent review.
• code_review.yaml: the default pipeline written out, custom reviewers, the description stage, declaring a gatekeeper, budgets, permissions, and every field.
• Spend limits: the account-wide caps review spend counts toward.