Gatekeeper

A gatekeeper is one agent that decides which reviewer findings you see. It is the last stage before anything reaches your pull request, and its job is subtraction.

It is off by default. The built-in pipeline is one careful reviewer, briefed to file a finding only when it can point at the line that is wrong and name the input or state that breaks it, so there is nothing for a second pass to arbitrate. A gatekeeper is a second frontier-model read of the same diff: it doubles a review's cost and its latency. Add one when you are getting findings you would rather not have read, most often because you run several reviewers of your own, or a reviewer whose prompt is deliberately eager.

What a gatekeeper does

It is not a second reviewer and goes looking for nothing of its own: for each claim it reads the diff and the surrounding code, then rules.

reviewer findings (5)          gatekeeper verdict              pull request (2)

rest_period.py:84  tz mix   ─▶ approve                      ─▶ comment posted
expiry.py:41  never expires ─▶ approve                      ─▶ comment posted
rest_period.py:88  tz mix   ─▶ merge: same defect as :84       folded into :84
routes.py:19  null deref    ─▶ reject: guarded at line 12      dashboard only
shift.py:55  rename helper  ─▶ reject: style, not a defect     dashboard only

A finding is rejected when it does not hold against the code as it stands, is already handled somewhere the reviewer did not look, is a style preference, or is speculative with no concrete failure behind it. Two findings about the same defect are merged into the clearer one, and a finding whose defect is real but whose explanation would mislead you is rewritten rather than dropped.

Nothing is deleted. Every proposed finding appears on the reviews dashboard with its verdict and the gatekeeper's reason verbatim, and the posted review states the counts: "Ran 1 review agent producing 5 comments where 2 were posted". With no gatekeeper the review says so plainly, so a reader knows the comments are the reviewer's own words.

Declaring one

Add a filter: block to your pipeline file. It takes exactly one agent as a mapping, with the same claude block an agent config uses; a list with entries is a validation error. A file that sets only filter: keeps the built-in reviewer and adds the gate in front of it:

ellipsis:
  version: v1
  kind: code_review
  name: Reviewed behind a gate

filter:
  name: gatekeeper
  claude:
    model: claude-opus-5
    system: |
      Approve only findings a staff engineer would raise in review.
      Reject style opinions, anything a linter catches, and any claim
      you have not verified against the surrounding code. Four sharp
      comments are worth more than twelve mediocre ones.

Run it on claude-opus-5 unless you have a reason not to: verifying a claim against real code is the same job as finding one, and the gatekeeper decides everything you read, so it is not worth doing cheaply. It comes out of the same budget.run as the reviewers, so raise the budget when you add one.

The prompt is the whole standard. To loosen it, say so: "approve any finding that describes a plausible defect, even if unverified". The commit range and the verdict mechanics are handled by Ellipsis, so never restate them. Before retuning, read the rejection reasons on the dashboard: real findings rejected means too strict, nitpicks posting means too lax.

Turning one off

Delete the filter: block. filter: [] is also accepted and does the same thing, as an explicit statement that this pipeline gates nothing:

filter: []

There is no case where you need the empty form to escape an inherited gatekeeper. A pipeline file inherits from the built-in pipeline, which has no filter, and never from another file: a repository's own code_review.yaml replaces your organization-wide one outright rather than layering onto it. So a repository that leaves filter: out runs no gatekeeper even when the organization-wide file declares one.

Field shapes and defaults are in the configuration reference.