Your first review

Open a pull request against any connected repository. There is no button to press and no workflow to add — GitHub notifies EasyMerge, and the review starts within seconds.

Open it as a draft and nothing happens yet: drafts are skipped by default, and the review starts when you mark it ready for review. See Skip draft pull requests.

On the pull request

Three things appear, in this order:

1. The check run. EasyMerge Review shows up in the PR's checks list as queued, then in progress.

2. The review. One GitHub review from the EasyMerge app. Its body opens with a recommendation — from ⛔ Blocked down to ✓ No issues found — then a short written summary of the change, the finding counts with a merge confidence reading, and a footer counting the files reviewed and skipped.

   The recommendation is wording in the body, nothing more. EasyMerge always submits its review as a comment, so Blocked blocks nothing and Changes requested is not a GitHub changes-requested review.

3. The inline comments. Each finding is attached to the line — or line range — it refers to, most severe first.

Because everything is posted as a single review, you get one notification instead of one per comment.

Reading a comment

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

<Critical badge> · **Config file is read on every request**

`readFileSync` blocks the event loop here; this handler runs on every request.

**Suggested change**

```suggestion
const contents = await readFile(configPath, 'utf8');
```

GitHub renders that as a Commit suggestion button, so applying the fix is one click. Suggestions are proposals — read them before committing.

Severities are critical, warning, and info, and every finding carries the same badge in the dashboard. Pure style and formatting are not reported — that is your linter's job.

Following it in the dashboard

Open Reviews to watch progress live — the status updates as the review progresses, without a page refresh. The list has one row per pull request, showing the state of its latest review; you can filter it by repository, by review status, and by PR author.

Opening a review shows every finding grouped by file, with line references such as lines 44–45 for multi-line comments, a summary bar (12 / 12 files reviewed, the comment count, how long it took, and the merge confidence), and a link straight to the pull request on GitHub.

If a PR has not been reviewed, the page says so plainly: No review yet for this PR. Push a commit or open the PR to trigger an AI review.

Getting a fresh review

Push a new commit. Every push to the PR branch starts a new review of the updated diff; the previous review's comments stay on the pull request as history.

A commit that has already been reviewed is not reviewed again, so reopening a pull request you have not pushed to changes nothing.

Closing or merging a pull request while a review is still running cancels it — you will not get comments on a PR you already merged.

If nothing happens

• Reviews may be disabled for that repository — check the toggle on its settings page.
• The pull request may still be a draft. Mark it ready for review.
• The file may be excluded. Lock and dependency metadata, build and coverage output, bundles, generated code and snapshot directories are skipped by default — the review detail labels those files excluded.
• GitHub gives no diff for binaries and oversized files. Those are labelled too large.
• A very wide pull request may have gone past Max files per review; the extra files are skipped.
• The pull request may have no reviewable changes at all, in which case the review completes with no issues found.