Gatekeeper

Reviewers propose findings; the gatekeeper decides which ones you see. It is the last stage before anything reaches your pull request, and its job is subtraction: you get fewer, better comments.

What the gatekeeper does

The gatekeeper is one agent that judges every proposed finding. 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".

The built-in gatekeeper runs on claude-opus-5, the same model as the built-in reviewer: 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.

Tuning it

Before changing anything, read the rejection reasons on the dashboard. They tell you which direction to tune: real findings rejected means too strict; nitpicks posting means too lax.

Override the gatekeeper with a filter: block in 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 replaces the gatekeeper:

ellipsis:
  version: v1
  kind: code_review
  name: Stricter 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.

To loosen it instead, say so in the prompt: "approve any finding that describes a plausible defect, even if unverified". The prompt is the whole standard; the commit range and the verdict mechanics are handled by Ellipsis, so never restate them.

To run no gatekeeper at all, set the disable idiom:

filter: []

Every reviewer finding then posts as written, and the posted review says so plainly: expect more noise, and the same issue raised more than once. Useful when you are evaluating a custom reviewer and want to see its raw output.

Field shapes and defaults are in the configuration reference.