Reading a review

A completed review has two parts: a body that summarises it, and one inline comment per finding.

The review body

The body opens with an EasyMerge review heading and a recommendation callout, followed by the counts and — when the review has findings — a row of severity badges:

## EasyMerge review

> [!CAUTION]
> **⛔ Recommendation: Blocked**
>
> Two of the three new handlers read the config file on every request.

**3 findings across 2 files** — <Confidence: 6.0/10 · Medium>

<Critical: 1> <Warning: 1> <Info: 1> · <High impact: 0>

---

Reviewed all 5 files · View full review in EasyMerge →

Each <…> above is a small coloured badge on the pull request, not plain text: one per severity carrying its count, one for the high-impact count, and one for the confidence reading.

The recommendation comes from the most serious finding in the review:

Recommendation	When
◌ Findings kept in EasyMerge	there were findings, but none was posted inline
⊘ Nothing to review	no file was read: all were excluded or undiffable
⛔ Blocked	at least one critical finding
⚑ Changes requested	at least one warning, no critical
◉ Comments	only info findings
↻ Incomplete	no findings, but some files were skipped
✓ No issues found	no findings and nothing skipped

The first two carry fixed wording instead of written prose: None of the findings met the repository's comment severity or limit settings, so nothing was posted inline. and Every changed file was excluded by the repository settings or had no reviewable diff.

The recommendation and the badge counts cover every finding the review kept, including any that were not posted inline. So a body can read ⛔ Blocked while the critical finding behind it sits in the dashboard rather than on a line of your diff.

When findings were held back, a line under the badges says how many:

2 findings are not posted inline (severity filter, comment limit, or already
raised by another run) — see them in EasyMerge.

The prose under the recommendation is written for your pull request, so it changes every time. Occasionally it is missing: the findings still go up, and the body keeps the same shape, without the prose and without a confidence reading.

The review is always submitted as a comment, never as Approve or Request changes. EasyMerge does not vote on your pull request.

The footer

The footer counts files and links back to the review in EasyMerge:

Reviewed all 5 files · View full review in EasyMerge →

When files were skipped, they are counted and grouped after the reviewed count — 3 skipped (excluded), or 5 skipped (2 excluded · 3 no diff) when more than one kind was involved. The group labels are excluded, no diff, file limit and other.

Merge confidence

Alongside the finding counts, the body carries a confidence reading out of 10 — how safe the change looks to merge given what the review found.

Reading	Score	Meaning
High	8.0 and above	safe to merge
Medium	above 5.0, below 8.0	review before merging
Low	5.0 and below	do not merge

A review that finds nothing reads 10.0/10 · High. A review that could not produce a reading carries none at all, and counts as Unrated on the dashboard.

Confidence rates the pull request as the review saw it. It does not take your CI checks or test coverage into account, it is not a promise that the change is correct, and it is not a substitute for a human reviewer.

Inline comments

Each finding is anchored to the line it is about. That is usually a line the pull request added or kept, but a comment can also sit on a line the change removed, on the old side of the diff.

A finding that spans several lines is posted as a multi-line comment covering the whole range; a range never crosses from one side of the diff to the other. The dashboard labels these lines 44–45, and a single-line finding line 44.

A comment opens with a severity badge and a short headline, then the explanation, and — where a concrete fix is possible — a suggestion block:

<Warning badge> · **Config is re-read on every request**

This runs on every request but the result never changes; hoist it out of the handler.

**Suggested change**

```suggestion
const compiled = compileTemplate(source);
```

The headline is a one-line summary, short enough to stay readable when GitHub collapses the thread. The badge is one of critical, warning or info, so you can tell at a glance how serious a finding is without opening the dashboard.

A finding that reaches across the change carries a second badge, High impact, beside the severity one, with a Why this matters section you can expand.

GitHub turns the suggestion into a Commit suggestion button, so applying the fix is one click. Suggestions replace exactly the line range the comment covers, and they are proposals — read them before committing.

Severities

Severity	What it means
critical	Broken functionality, a security vulnerability, data loss or corruption, a crash, an injection or auth flaw
warning	A likely bug or unhandled edge case, a race condition, missing error handling, a resource leak, a significant performance problem
info	Maintainability, a misleading name or comment, a minor improvement

Severity is judged per finding and then reconsidered with the whole pull request in view — a problem that looks critical while reading one file alone may be posted as a warning once the rest of the change explains it, and the other way round.

Pure style and formatting are not reported. Indentation, quote style and line length are left to your linter.

NOTE

Reviews used to label the highest level error instead of critical. Comments from those older reviews keep the label they were stored with, and appear in the dashboard as a plain grey error badge. Nothing is lost — the finding still reads the same, and new reviews use critical.

The order comments arrive in

Comments are created most severe first — critical, then warning, then info — with High impact findings first inside each severity. Comments for the same file stay together.

How GitHub then lays them out is up to GitHub: in Files changed each one is anchored to its own line, so you read them in diff order regardless.

Why a finding might not appear

Not everything the reviewer notices is posted:

• The line must be part of the diff. A finding is checked against the actual content of the line it names. If that content turns out to be on a different line, the comment is moved to the right one; if it matches nothing in the diff, the finding is dropped rather than posted in the wrong place.
• The file must have been reviewed. Excluded files, files GitHub gives no diff for, and files past the file cap are never read — see Excluding files.
• A multi-line range must hold up. If the start of the range is not a real line before the end, the finding is posted as a single-line comment on its end line instead of being dropped.
• It must survive the whole-pull-request check. Before anything is posted, every finding is judged once more against the full change. One that does not hold up — because the rest of the change already handles it, or because it describes intended behaviour — is not posted. When two findings report the same issue on the same lines, the clearest one is kept.
• Its severity must be one you post. Only the levels ticked under Comment severities are posted inline. info is off by default.
• It must fit under the comment limit. With Max comments per review on, a review posts at most that many inline comments — most serious first, so the ones cut are the least important.
• It must not repeat an earlier run. A finding another review of the same commit has already raised is not posted a second time.

That whole-pull-request check is also why a review can come back with a summary and no inline comments at all, and why the same code can produce fewer comments than it did last time.

Findings held back by the last three reasons are not lost. They are listed in the review detail, each labelled with why it stayed there — not posted · severity filter, not posted · comment limit or not posted · already raised by another run — and counted in the review body.

What EasyMerge will not do

• Approve, request changes, or block a merge.
• Comment on files you did not touch in this pull request.
• Edit or resolve its earlier comments — the history of past reviews stays on the PR.