Read a review in GitLab or GitHub

When Gryndel reviews a merge request (GitLab) or pull request (GitHub), it posts on it like a colleague would. In GitLab its comments come from the Gryndel user (username gryndel). On GitHub, Gryndel is a GitHub App, so they come from the App's bot account, named after the App with [bot] on the end, such as gryndel-acme[bot]. This page walks through a review from top to bottom, explains every label and score, helps you decide whether a finding is right, and shows how to respond so that the next review, your colleagues, and Gryndel's Reports all get the message.

What Gryndel posts is the same on both hosts, worded in each host's terms ("pull request" and #12 on GitHub, "merge request" and !12 on GitLab). The examples on this page use GitLab's words. Where the two hosts work differently, the page says so.

A review from top to bottom

Say you push a commit to a merge or pull request in a repository Gryndel reviews. Within a few seconds to a few minutes, depending on the size of the change and the model, this appears on it:

1. A progress comment saying Gryndel is reviewing the commit. It's updated when the review ends.
2. A summary note headed Gryndel review, listing what was found and how confident Gryndel is.
3. One thread per finding, attached to the line it's about.
4. A commit status named gryndel/review, passed or failed.

Where to find each one:

What	GitLab	GitHub
Progress comment and summary	Comments on the merge request's Overview tab	Comments on the pull request's Conversation tab
Finding threads	On the line in the Changes tab, and on the Overview tab	Review comments on the line in the Files changed tab, and on the Conversation tab
Commit status	The merge request's pipeline area, and next to the commit	The checks list near the merge button at the bottom of the Conversation tab, and next to the commit

Read them in that order: the summary tells you how much there is and how serious it is, the threads tell you what to do, and the status tells you whether it blocks the merge.

The progress comment

As soon as a review starts, Gryndel posts:

⏳ Gryndel is reviewing this merge request (commit 1a2b3c4d5e6f, verified review). Started 2026-10-22 14:05 UTC. Large merge requests can take several minutes. This note is updated when the review finishes.

The word before "review" is the repository's review mode: single (one pass, no separate check), verified (a draft, then an independent check of each finding) or agents (several specialist reviewers, then a check). When the review ends, the same comment changes to one of these:

The comment says	Meaning	What to do
✅ Gryndel finished reviewing this merge request	Done. It says how many findings were posted. Partial review means some review agents didn't finish, so part of the change may not have been looked at.	Read the summary and threads. After a partial review, comment @gryndel review to try again.
⏹️ Gryndel stopped reviewing this merge request	Someone cancelled it, and says who.	Comment @gryndel review to start again, or push.
❌ Gryndel could not finish reviewing this merge request	Something went wrong. The reason follows.	Tell a workspace admin. They can replay the review once the cause is fixed. See Troubleshooting.

There's only one progress comment per merge or pull request. Each review, including the one for your next push, rewrites it.

The summary note

Each finished review posts or updates one note headed Gryndel review:

Line	What it tells you	How to use it
Findings list	Each posted finding with its severity, or No publishable findings.	Start with the P0s. "No findings" doesn't prove the change is free of defects.
Withheld candidates	Possible problems Gryndel found but didn't post: rejected by the verification check, below the repository's minimum severity, beyond the comment level, dismissed earlier, or not on a changed line (anchor failures).	A high number is normal in Verified and Agents modes. You can read each one, and why, on the review's Withheld tab in Gryndel.
Coverage limits	Only shown when part of the change wasn't reviewed, for example files that were too large.	Review those parts yourself, or ask an admin about the repository's limits.
Files reviewed	How many files were reviewed, and how many were left out at the start.	Check this on large merge or pull requests.
Agents	In Agents mode: which review agents were chosen for this change, out of how many.
Repository profile	Whether Gryndel has learned the repository, and whether this review followed the profile.	If it says not learned, an admin can learn the repository for better reviews.
Merge confidence	A score from 0 to 5, worked out by Gryndel's code (not the model) from the findings: 5 with none. A P0 finding caps it at 1, each P1 takes off a point, and P2s take off a little. It's lower when files were skipped.	A quick sense of how ready the change is.
Risk	low, medium, high or critical, from which paths changed, with the reason. Authentication, security, payments, migrations, infrastructure and CI files count as critical, and dependency and build files as high. The model can raise it, never lower it.	High-risk changes deserve a careful human review whatever Gryndel found.
Review confidence	A score from 0 to 5: how sure the verification check was about its decisions. It's capped at 2 when an agent didn't finish, and at 3 when files were left out.	A low score means: don't treat "no findings" as reassurance.
Model and Commit	The model that ran the review and the commit it reviewed.	Make sure the commit is your latest.

The scores are information for you. They don't change the commit status. Like the progress comment, there's one summary note per merge or pull request, updated by each review.

Finding threads

Each finding is its own thread on a changed line: a discussion thread in GitLab, a review comment in GitHub. For example:

issue (blocking, security): P0 · Access token written to the application log

login() logs the whole request, including the Authorization header, at INFO level. Anyone with log access can reuse the token until it expires. Log the user ID instead.

Suggested fix: (a GitLab or GitHub suggestion with the changed line)

Rule: No PII in logs

Found by: security, logging

The first line

issue (blocking, security): P0 · Access token written to the application log

1. The label says what kind of comment it is. Gryndel uses Conventional Comments, a common convention for review comments:

   Label	Meaning	Expected from you
   issue	A real problem. In Verified and Agents modes, every issue passed an independent check before it was posted.	Fix it, or say why it's wrong.
   suggestion	An improvement worth considering. Agents mode only.	Your call.
   nitpick	A small style or wording point. Agents mode only.	Optional.
   question	A possible problem the verification check couldn't confirm or rule out. Agents mode, Chatterbox level only.	Confirm or explain.

   In Single pass and Verified modes, every finding is labelled issue.

2. Decorations, in brackets:

   • blocking: this finding fails the commit status (see The commit status). Only issues at or above the repository's threshold are blocking.
   • non-blocking: information only. It doesn't fail the status.
   • security: the finding is about security.

3. The severity:

   Severity	Meaning	Example
   P0	Critical: a security hole or data loss.	SQL built from user input; a migration that drops a column still in use.
   P1	Realistic incorrect behaviour that users or callers would hit.	An off-by-one that skips the last page of results; an unhandled None on a common path.
   P2	A minor real issue.	A misleading error message; a resource closed late.

4. The title, a one-line summary. The explanation follows below it.

The extra lines

Line	Meaning
Suggested fix	A suggestion in the host's own format: a small code change you can apply with one click. See Apply a suggested fix.
Rule:	The rule the finding enforces. It's a convention finding (your team's policy), not a bug.
Found by:	The review agents that found it, in Agents mode. Several agents agreeing is a good sign.
Outdated: a newer Gryndel review supersedes this commit.	Added to findings from an earlier commit. See What happens when you push again.

Comment levels

In Agents mode, the repository's Comment level sets how much besides issues gets posted. Issues are always posted, whatever the level.

Level	What gets posted	Choose it when
🤫 Whisper	Verified issues only.	The team wants only problems that need fixing.
💬 Chat (default)	Issues, plus up to 3 suggestions.	Most teams.
📣 Chatterbox	Issues, plus up to 8 suggestions, 8 nitpicks and 5 questions.	A new team or codebase where extra advice is welcome.

A review posts at most 25 findings in Agents mode, issues first. An admin sets the level on the repository's Findings tab in Repositories.

The commit status

Gryndel sets a commit status named gryndel/review on the reviewed commit when the review finishes. In GitLab it shows in the merge request's pipeline area as passed or failed. On GitHub it shows in the pull request's list of checks, with the description Gryndel review completed and a green tick or a red cross.

• Failed when at least one finding is blocking, or the review was partial. A partial review never passes, so an unfinished review can't look clean.
• Passed otherwise.

Which severities block is set per repository, in Fail commit status on:

Setting	Fails the status on
P0 findings	Critical issues only. This is the default.
P0 or P1 findings	Critical issues and realistic incorrect behaviour.
Any published finding	Any issue that is posted.
Never fail	No finding fails it. A partial review still fails.

Suggestions, nitpicks and questions never fail the status.

Make the status block merging

The status on its own is information. It blocks merging only if the repository requires a passing status before merging:

Host	Setting
GitLab	Pipelines must succeed, in the project's merge request settings.
GitHub	A branch protection rule (or ruleset) on the target branch that requires status checks to pass before merging, with gryndel/review chosen as a required check. GitHub usually lists a check there only after it has reported on the repository recently, so let Gryndel review one pull request first.

With that in place, a blocking finding stops the merge until a new commit is reviewed without it. Dismissing or resolving the thread doesn't change the status of the commit that's already reviewed: push the fix, or ask for @gryndel review after an admin changes the threshold.

The exact options depend on your GitLab or GitHub version and plan, so test the setup before relying on it: open a test merge or pull request with a deliberate problem, such as a hard-coded password, and check that merging is blocked while the status is failed. Remember that a review can take minutes: until the status is set, GitHub shows a required check as Expected and waits for it. The guide to stricter reviews walks through the setup step by step.

Decide whether a finding is right

Gryndel is usually right about issues, but it's an AI model and can be wrong. Before acting, spend a minute on these:

1. Find the scenario. A good finding says what input or sequence triggers the problem. Can that happen in your code? For example, can this value really be None here?
2. Look beyond the diff. Gryndel mainly sees the changed files. A check in a caller or a middleware it didn't see may already prevent the problem.
3. Check the label and severity. A question is Gryndel saying it isn't sure. A P0 deserves a careful look even if you suspect it's wrong.
4. Check the Rule line. If it cites a rule, the question is whether the code breaks your team's policy, not whether it's a bug.
5. Still unsure? Reply @gryndel explain in the thread, adding your doubt as a question. Gryndel answers with the triggering scenario and a concrete fix.

Respond to a finding

How you respond tells your colleagues, the next review, and Reports whether the finding was useful.

The finding is	Do this	Reports count it as
Right, and the fix is the suggestion	Apply the suggestion: Apply suggestion in GitLab, Commit suggestion on GitHub	Fix applied (accepted) in GitLab. On GitHub, Resolved (accepted) once the thread is resolved, by you or by the next review
Right	Fix the code, push, and resolve the thread (or let Gryndel resolve it: see below)	Resolved (accepted)
Right, but you're deliberately not fixing it in this merge or pull request	Reply with why, then @gryndel ignore this	Dismissed (rejected)
Wrong	Reply with why, then @gryndel ignore this, or react 👎 on the finding and resolve the thread	Dismissed or Disputed (rejected)
Unclear	Reply @gryndel explain	Decided later
Useful, and you want to say so	React 👍 on the finding	Counts towards the finding's 👍 and 👎 balance
Left alone until the merge	Nothing	Left open

When several apply, Reports pick one outcome in this order: Dismissed, then Disputed (more 👎 than 👍 on the finding's first comment), then Fix applied, then Resolved. Replies are counted too. GitHub doesn't tell Gryndel when a suggestion was committed, so on GitHub there is no Fix applied: the finding counts as Resolved once its thread is resolved.

About resolving: a resolved thread counts as Resolved, which means accepted. That includes threads resolved with @gryndel resolve, by @gryndel check, and by Gryndel when a newer review replaces them. To record that a finding was wrong, use @gryndel ignore this or 👎 rather than just resolving it.

Replying is useful. A short reason in the thread ("The token is already redacted by the logging filter in log_config.py") helps reviewers, and @gryndel check takes replies into account. Gryndel never resolves a thread that people have replied in by itself.

Gryndel reads these responses back from GitLab or GitHub about every 10 minutes while the merge or pull request is open, and once more after it's merged or closed. On the Reports page, click Refresh to read them now. See Reports.

For the commands mentioned here, see Commands in merge and pull requests.

Apply a suggested fix

When the fix is small and clear (up to 30 lines, on the new side of the change), the thread includes a suggestion: the proposed code shown as a diff, which you can commit from the merge or pull request.

GitLab

1. Read the suggestion. Check it does what the explanation says, and nothing else.
2. Click Apply suggestion. You need permission to push to the source branch. You can also add several suggestions to a batch and apply them in one commit.
3. GitLab commits the change to the source branch. That push gets a new review.

GitHub

1. Read the suggestion. Check it does what the explanation says, and nothing else.
2. Click Commit suggestion and confirm the commit. You need permission to push to the pull request's branch. You can also add several suggestions to a batch and commit them together.
3. GitHub commits the change to the branch. That push gets a new review.

GitHub can only suggest changes to lines its diff shows. When Gryndel's fix reaches beyond them, the finding shows the replacement as plain code, headed Replacing lines 12-18:, for you to copy into your editor instead.

Repository settings can change this, in Suggested fixes:

Setting	What happens
Suggest fixes (default)	Findings carry suggestions; people apply them.
Suggest and apply fixes	GitLab only. Gryndel also commits all its suggestions to the source branch after each review, in one commit, which is then reviewed too. It needs permission to push there, and never fixes its own commit.
Don't suggest fixes	No suggestions.

On GitHub

GitHub has no way for an app to commit suggestions, so Suggest and apply fixes works like Suggest fixes on GitHub, plus a comment on the pull request after each review that had suggestions: ⚠️ Gryndel could not apply its suggested fixes. The suggestions stay on the findings for you to commit with Commit suggestion.

What happens when you push again

Each push starts a new review of the new commit. If a review of an older commit is still running, it's abandoned and posts nothing.

When the new review has posted its findings:

• Problems still there are posted again, as new threads on the new commit. You don't have to hunt for them in old threads.
• Problems you dismissed with @gryndel ignore this aren't posted again on this merge or pull request.
• Threads from earlier commits get a line added: Outdated: a newer Gryndel review supersedes this commit. This does not prove the issue was fixed. Gryndel then resolves them, unless someone replied in the thread: threads with people's replies stay open for you to close. In GitLab, a thread whose suggestion was applied isn't edited, but is resolved the same way.
• The progress comment and summary note are rewritten for the new commit.
• The new commit gets its own commit status. The old commit keeps its status.

If the new review fails or is cancelled, the earlier threads are left as they were.

So the usual loop is: read the threads, push fixes, and read the new review. Comment @gryndel check when you also want a reply in each open thread, for example after replying with explanations, or when automatic reviews are paused. If you comment @gryndel pause, pushes aren't reviewed until you comment @gryndel resume or @gryndel review.

Related pages

• Commands in merge and pull requests
• Findings, to see findings across all merge and pull requests in Gryndel
• Reports, to see what people did with findings
• Repositories, for comment level, severity and commit status settings