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.
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.
