Code review
One review per push, written by the reviewers you define.
A code review is a kind: code_review file that names which pull requests to review and a list of reviewers, each a session with its own prompt, model, environment, and budget. Each push the file admits gets at most one review on the pull request, combining every reviewer's findings.
Review every push
Install the Ellipsis GitHub App on your repository, then commit this file to its default branch:
Open a pull request to see it work. Each push starts the reviewers whose paths match the new commits, and one review from ellipsis-dev[bot] lands with their comments. A reviewer only sees commits it has not reviewed before, and a comment on a line outside those commits is held back. A push with nothing new for any reviewer starts nothing. Every review, with each reviewer's comments and session, is listed under Code Review in the dashboard.
What the review posts
Each reviewer marks every comment blocking or not. A review passes when no reviewer returned a blocking comment and fails otherwise. output sets the GitHub review submitted in each case:
on_pass is silent (nothing is posted unless a reviewer left a non-blocking comment, which posts as a comment), comment, or approve; on_fail is comment or request_changes. A failed review posts its on_fail event whether or not any of its comments lands on a changed line. A review in which a reviewer stopped early never approves, and a pull request the Ellipsis app opened itself gets a comment in every case, because GitHub refuses an approval or a request for changes from a pull request's own author. With summary: true every reviewer also returns a summary, and the review body opens with it, above the platform's own details; the prompt says what the summary should contain. Without output, a pass is silent and a fail is a comment.
Configure a review
A file holds up to 8 reviewers, each with a unique name, and a repository holds one file. pull_requests takes the same filters as a pull request trigger. A reviewer takes the same environment, skills, and permissions blocks as an agent session; its budget takes only session. Every reviewer's GitHub token reads the contents and pull requests of the repository under review; permissions.github can add read scopes and repositories, never write, because the platform posts the review. See the Code review schema reference for complete examples and every field.
A file in the .ellipsis repository reviews every repository its pull_requests.repositories filter admits; a file in a repository reviews that repository and wins over the organization file. A file that breaks a limit or does not parse fails the sync, keeps the last good version running, and shows the error in the Ellipsis config check on the pull request.
What happens when a reviewer fails
A review posts at most 30 comments per reviewer and 60 per review. A reviewer that returns more than 30 fails and contributes nothing; comments past 60 are kept with the review but not posted. A blocking comment on a line the push did not change is held back but still fails the review, which posts its on_fail event with the comments that did land. When no reviewer finishes, nothing is posted and nothing is marked reviewed. A reviewer that fails or runs out of budget contributes nothing; the review still posts with the other reviewers' comments, never as an approval, and that reviewer covers the same commits again on the next push. When GitHub rejects the review, the review ends with status failed, nothing posts, and every reviewer covers the same commits again on the next push.