← Docs

How a review works

Last updated 4 October 2026.

What does MergeSafe do when it reviews a pull request?

MergeSafe reads the change in your pull request, checks each finding before posting it, and posts a summary with a merge readiness score out of 5, inline comments ranked by severity, and a mergesafe-review check run on the commit.

Step by step

Something starts it. By default a pull request is reviewed when it opens and on each new commit, shortly after the branch stops moving. You can also ask with @mergesafe review, the Review now button in the app, or the API. Draft pull requests aren’t reviewed. See When reviews run.
It checks who and how big. A pull request from an author the repository doesn’t review is skipped at no charge (Whose pull requests are reviewed). Over 2,000 hand-written changed lines it asks before reviewing; over 5,000 lines or more than 60 files it doesn’t review (Large pull requests).
It reviews the change. The review covers what the pull request changes, at the repository’s level, and reads other files in the repository to follow a call or a data path. Your repository’s AGENTS.md and .cursor/rules/ files are applied as rules, read from the base branch. Every level includes the Standard security review.
It checks its findings. Findings are checked against the code before they are posted; Strong and Ultra verify every finding. One that could not be verified is labelled unverified, and lowers the score only if it is P0 or P1.
It posts the review. See the list below.

What you see on the pull request

A summary comment with the score (for example 4.5/5), the count of findings per severity, the review level, the security result and the commit reviewed. Blocking findings (P0 and P1) are listed in a table; the rest are in a collapsed section.
Docs that may be out of date. If the pull request renames, moves or deletes something your agent-instruction files name (AGENTS.md, .cursor/rules/, .github/copilot-instructions.md and similar), the summary lists each stale reference with a suggested edit. These are suggestions only and never change the score.
Inline comments on the lines that need attention: a severity badge, the problem, a suggested fix and a prompt you can paste into an AI coding agent. Up to 20 per review, with P0 and P1 findings placed first; any finding not posted inline is still listed in the summary.
A check run named mergesafe-review. It fails while a P0 or P1 finding is open and passes otherwise, so you can make it a required check in branch protection.
A section in the pull request description: what changed, its impact and its risk, plus a review history table with one row per reviewed commit. Your own text in the description is kept.

MergeSafe comments; it never approves or requests changes on its own.

When you push again

The next review covers what changed since the last reviewed commit. New inline comments go only on lines that changed.
Open findings carry forward and are checked again; fixed ones are counted as resolved in the review history.
Small follow-up changes are reviewed at half price.
A rebase that leaves the pull request’s diff unchanged carries the previous review to the new commit, with no charge.

Next: Review levels →