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 enables it, on the Settings tab of /reviews in the dashboard. No YAML required: 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 it 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. When priya-shah pushes twice more over the afternoon, each push gets a review of what that push added. See Which PRs get reviewed.
• 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, so a review is a short list of real problems rather than a page of "consider whether".
• Comments anchor to the reviewed commit, so they stay attached to the right lines as the pull request grows.

An optional pipeline file scopes which pull requests get reviewed and customizes the reviewers; the toggle alone runs the built-in pipeline everywhere. One filename, code_review.yaml, and 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. See Which PRs get reviewed.

How it runs

A review is a pipeline. A description agent keeps the pull request description summarized, reviewers read the new commits in parallel, their findings are deduplicated, and Ellipsis posts one pull request review. An optional gatekeeper stage can judge every finding first:

push lands on splitshift-api#519
        │
        ▼
  pre_review       gather context for the reviewers, or cancel a
                   review the range does not need
                   (not in the default pipeline)
        │
        ▼
  description      keeps the PR description's summary current;
                   applied to the PR body as soon as it settles
        │
        ▼
  review           each reviewer reads the new commits in parallel
                     bugs: 5 findings            (the default one)
                     migration-safety: 2         (one you declared)
        │
        ▼
  deduplication    identical findings collapse: 7 -> 6
        │
        ▼
  filter           a gatekeeper you declared checks each claim
                   against the code: 6 -> 2
                   (not in the default pipeline)
        │
        ▼
  posted review    one PR review, its comments anchored to the
                   commit it reviewed: 6 as the default runs,
                   2 behind the gatekeeper above

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, concurrency, security, regressions). The reviewer reads the surrounding code, not the diff alone, because most real findings depend on a caller or a guard the diff does not show, and it files a finding only when it can name the input or state that breaks the line. pre_review, filter, and post_review are empty by default.

A pipeline file can replace the reviewers with your own, add a gatekeeper that judges their findings before anything posts, and cap spend. See Configuration YAML.

Ellipsis itself posts the final review; reviewers never post directly. A review that finds nothing posts a one-line clean summary rather than invented nitpicks. See Permissions.

Pages in this section

• Quick start: turn reviews on and watch the first one land.
• Configuration YAML: the optional pipeline file, every field, and budgets.
• Which PRs get reviewed: where a pipeline file lives and what it governs, incremental scope, the filters, and when a push produces no review.
• Pull request descriptions: the summary Ellipsis maintains at the top of every pull request, and writing your own description agent.
• Reviewers: the default reviewer, and writing your own in its place.
• Gatekeeper: the optional filter stage that judges findings before they post, and when it is worth its cost.
• Permissions: what posts the review, stage sandbox permissions, and commit anchoring.
• Guides: problem-shaped walkthroughs, starting with reviewing every pull request as commits land.