GitLab Merge Request Review Agent

Posts one structured review note on every merge request as it opens or gets pushed to, with checklist verdicts, pipeline state and real questions, and it never approves, merges, or closes anything.

0 in use9
Loading preview…
Guided setup — test it before connecting anything.

Watch it work before it's live

Run a staged conversation — no account needed. The agent handles it for real while a simulated world answers its tool calls; nothing touches real accounts, and nothing is actually sent.

Add idempotency keys to the refunds endpoint

Open

@fatima.zahra

Adds an Idempotency-Key header to POST /refunds and stores the key against the refund for 24 hours, so a retried request returns the original refund instead of issuing a second one. Migration adds one table and a unique index. Twelve files, 340 lines added, 46 removed. Unit and integration tests included, pipeline green on the head commit. Closes issue 2841.

Set up in minutes

Using this template drops you into a guided setup. It asks exactly this, nothing else:

  1. Connect GitLab

    One sign-in. The agent acts through your account, scoped to what this template uses.

  2. Connect Slack

    One sign-in. The agent acts through your account, scoped to what this template uses.

  3. Review checklist

    What a merge request has to satisfy on this project in your own words, which of those items block a merge, and what you want asked of the author when an item cannot be judged from the diff alone.

  4. Choose which agent runs it

    NoClick's built-in models work out of the box — or bring Claude Code, Codex, and other coding agents on your own subscription.

  5. Watch it handle a test run

    A staged conversation against a simulated world — then it’s live.

About this agent

Merge requests wait because a first pass means reading forty commits before you can say anything useful, so they sit until somebody has an hour. This agent reads the diff, the commits and the pipeline the moment a merge request opens or gets pushed to, then posts one note that walks your checklist line by line and asks the two or three questions a reviewer would have asked anyway. It cannot approve, merge or close, which is the whole point: it does the reading, your reviewers keep the decision.

What people use it for

  • First pass in under a minute - The author gets checklist verdicts and questions while the change is still in their head, rather than the next morning when they have moved on to something else.
  • New reviewers get a map - The opening section describes the change from the diff itself, so somebody who did not write the code knows which files to read first and what the merge request is trying to do.
  • The same checklist every time - Migration notes, tests and whatever your team keeps forgetting get asked about on every merge request, including the one opened at 18:00 on a Friday by the person who wrote the checklist.
  • Approval stays a human decision - It has no power to approve or merge, so nothing ships because software liked it. The note is evidence a reviewer reads, not a green tick that clears the gate.

Before you fork

Can it approve or merge a merge request?

No. Its tools are reads plus posting a note, and it is instructed never to approve, merge, close, or push. Your approval rules are untouched. If you want that enforced by GitLab rather than by instruction, give its token the Reporter role, which can comment on a merge request and cannot merge one.

It posts on every push. Will that bury the thread?

Each note opens with what moved since the last one and drops points it has already made, so ten pushes give you ten short notes rather than the same review ten times. Events that are not merge request opens or updates produce nothing at all. Teams that still find it chatty cut the checklist down to blocking items.

What access does it need, and what does a busy week cost?

A GitLab credential that can read the project and create notes, and a Slack channel for blockers. It runs once per qualifying merge request event, so thirty merge requests with a few pushes each is roughly a hundred short runs in a week, and a quiet week costs nothing. Repository size does not change the number, only the volume of merge requests does.

Run it with your coding agent

Works with

More agents like this

Browse all agent templates →

Put GitLab Merge Request Review Agent to work

Free to start. Guided setup, a test run against staged conversations, and it's live.