Commands in merge and pull requests

You can talk to Gryndel from any merge request (GitLab) or pull request (GitHub) in a repository it reviews. Start a comment with @gryndel, then a command or a question, and Gryndel replies in the same thread. Commands let you review again, stop or pause reviews, dismiss a wrong finding, check your fixes, teach a rule, or ask about the change, all without leaving GitLab or GitHub. The commands and their answers are the same on both; this page points out the few places where the two hosts differ. Gryndel's replies quoted here use GitLab's words: on GitHub, Gryndel says "pull request" wherever they say "merge request".

On GitLab, commands also work with the username of the account Gryndel reviews as, for example @acme-reviewer review when that account's username is acme-reviewer. GitLab suggests that name as you type; @gryndel works just as well.

Quick reference

Command	Use it to	Write it as	Uses the model
review	Review the latest commit again	New comment	No
cancel	Stop the review that is queued or running	New comment	No
status	See what Gryndel is doing on this merge or pull request	New comment	No
pause	Stop automatic reviews of this merge or pull request	New comment	No
resume	Start automatic reviews of this merge or pull request again	New comment	No
check	Ask Gryndel to re-check its open threads against your fixes and replies	New comment	Yes
explain	Get a deeper explanation of one finding	Reply in the finding's thread	Yes
ignore this	Dismiss one wrong finding for this merge or pull request	Reply in the finding's thread	No
resolve	Resolve all of Gryndel's open threads without checking them	New comment	No
configuration	See the settings that apply to this merge or pull request	New comment	No
learn:	Teach a rule for future reviews of this repository	New comment	No
help	List the commands	New comment	No
Anything else	Ask a question about the merge or pull request	Either	Yes

Short forms also work: config or settings for configuration, stop for cancel, and progress for status. A comment with only @gryndel gets the help.

Who can use commands

Commands come from the people who can change the code, as the code host sees it:

Host	Who can use commands	If you can't, Gryndel replies
GitLab	The Developer role or higher in the GitLab project	Sorry @you, Gryndel commands need the Developer role or higher in this project.
GitHub	Write access to the repository (the Write, Maintain or Admin role, directly or through a team)	Sorry @you, Gryndel commands need write access to this repository.

After that refusal Gryndel does nothing else. Your role in the Gryndel web app doesn't matter: a Gryndel viewer who is a Developer (or has write access on GitHub) can use every command, and a Gryndel admin without that access can't.

Comments written by bots, including Gryndel's own, are never treated as commands.

Commands aren't answered while reviews are turned off for the workspace. Gryndel replies that it's turned off and to contact an administrator instead. See Workspace.

How to write a command

• Start the comment with @gryndel. A mention later in the comment, such as "Thanks @gryndel, review again", is ignored. A colon or comma after the name is fine: @gryndel: status.
• One command per comment. Only the first word after @gryndel is read as the command. The rest is passed along: as the question for explain, or as the rule for learn:.
• Case doesn't matter. @Gryndel Review works.
• New comment or thread reply. Most commands act on the whole merge or pull request and work anywhere. explain and ignore this act on one finding, so write them as a reply in that finding's thread.
• Editing a comment doesn't run it again. Post a new comment instead. Each comment is carried out once, even if GitLab or GitHub delivers it twice.
• Questions that start with a command word run the command. @gryndel review the error handling? starts a review, and @gryndel status of the migration? shows the review status. Start a question with another word, such as "what", "does" or "why".

Where to type commands

GitLab

Gryndel's replies come from the account it reviews as in your workspace. Start the comment with @gryndel or with that account's username: GitLab offers the username as you type. Your workspace's reviewer account usually has its own username, such as @gryndel-yourteam; the Workspace page shows it.

• New comment: the comment box at the bottom of the merge request's Overview tab.
• Thread reply: the Reply box under a finding, either on the Overview tab or next to the line on the Changes tab.

GitHub

On GitHub, Gryndel is a GitHub App, and an App can't be @-mentioned. @gryndel is simply the word Gryndel watches for at the start of a comment: GitHub doesn't autocomplete it, and may show it as a link to an unrelated GitHub user of that name, which doesn't matter. Gryndel's replies come from the App's bot account, <app name>[bot]. Whoever runs Gryndel can choose another word; if @gryndel gets no reply at all, ask them which word your Gryndel uses.

• New comment: the comment box at the bottom of the pull request's Conversation tab. Comments there aren't threaded, so Gryndel's reply is the next comment on the pull request.
• Thread reply: the Reply box under a finding, either on the Conversation tab or next to the line on the Files changed tab. Gryndel's reply goes in the same thread.
• Not read: the summary you write when you submit a review. Put a command in its own comment instead. A line comment you add as part of a review that you haven't submitted yet is still pending, and Gryndel only sees it once you submit the review.

Commands that use the model

check, explain and questions are answered by the AI model, using the workspace's default model provider (see Model settings). Gryndel replies at once to say it's on it:

👀 Got it, @you. Looking into your question. This can take a few minutes; I'll reply here when it's done.

If other model-backed requests are waiting, it adds how many are ahead of yours. The full answer follows in the same thread. These answers cost tokens, which appear on the Costs page. The other commands answer within seconds and cost nothing.

If something goes wrong, Gryndel replies Sorry @you, check did not work with the reason, for example a model setting to change. A request still unanswered after an hour, for example because Gryndel was restarted, gets did not finish: Gryndel stopped while working on it. Ask again.

review

When: you want a fresh review without pushing, for example after an admin added a rule or changed the model, after a review failed, or on a merge or pull request you paused.

@gryndel review

What happens: Gryndel replies Starting a new review of the latest commit, as requested by @you. The review runs even if this commit was already reviewed, and even if this merge or pull request was paused with @gryndel pause. If a review of it is already queued or running, the new one replaces it. The progress comment and summary are updated as usual (see Reading a review).

review only gets past a pause set on this one merge or pull request. It doesn't override a repository that an admin paused or turned off in Gryndel, a pause set for the whole organization, or a workspace whose reviews are turned off. In those cases no review runs, even though Gryndel still replies that it's starting one. Ask a workspace admin to turn the repository's reviews back on.

cancel

When: a review is taking long and you're about to push again anyway, or it was started by mistake.

@gryndel cancel

What happens: Gryndel stops the queued or running review within seconds and replies Stopped the review of commit 1a2b3c4d5e6f. The progress comment changes to Gryndel stopped reviewing this merge request, with who cancelled it. Nothing from the cancelled review is posted. The next push is reviewed as usual. If nothing is running, Gryndel replies No Gryndel review is queued or running for this merge request.

status

When: a review seems slow, or you want to know whether the latest commit was reviewed.

@gryndel status

What happens: Gryndel posts Gryndel review status: which commit it's reviewing, how long it has been running, which attempt this is, and each step with ✅ done, ⏳ running, ▫️ waiting or ❌ failed, with timings and retries. If nothing is running, it shows the last result: how many findings were posted and withheld, or why it failed. It also says if automatic reviews are paused.

pause and resume

When to pause: a merge or pull request gets many small pushes (work in progress, a long rebase) and you don't want a review of each one. When to resume: it's ready for review again.

@gryndel pause

Gryndel replies Automatic reviews of this merge request are paused. New pushes aren't reviewed until you resume. @gryndel review still runs one review on request, because this pause is the one it can get past.

@gryndel resume

Gryndel replies Automatic reviews of this merge request are back on; the next push is reviewed. Resuming doesn't review the current commit by itself; comment @gryndel review to do that now.

Pausing affects only this merge or pull request. To pause a whole repository, a workspace admin sets its Review processing to Paused, or turns its reviews off, on the Repositories page. On GitLab that removes the repository's webhook, so the admin also needs Maintainer access to the project; on GitHub nothing else is needed. While a repository is paused, @gryndel review doesn't run either. See Pause reviews for every level.

check

When: you pushed fixes, or replied to findings explaining why they're not a problem, and want Gryndel to look at each of its open threads again and close the ones that are dealt with.

@gryndel check

What happens: for each of Gryndel's unresolved finding threads (up to 20), the model reads the finding, the replies, and the code around it at the latest commit. Then in each thread Gryndel:

• resolves it, with a reply saying what fixed it, if the current code fixes the problem or a reply gives a correct reason it isn't one; or
• leaves it open, with a reply saying exactly what is still wrong and what would fix it.

Finally it replies to your comment with a summary, such as Checked 4 open threads against commit 1a2b3c4d5e6f: 3 resolved, 1 still open (see the replies in each thread).

check or a new review? Pushing a commit already starts a full review, which posts the problems that are still there and marks the old threads as outdated (see What happens when you push again). Use check when you also want a direct answer in each thread, when you've replied in threads (Gryndel never resolves those by itself), or when automatic reviews are paused.

explain

When: a finding is unclear, or you're not sure it applies.

Reply in the finding's thread:

@gryndel explain

You can add a question after it:

@gryndel explain why can this be null here? The caller always validates the token first.

What happens: Gryndel replies in the thread with the scenario that triggers the problem, what happens compared with what should happen, why it matters, and a concrete fix, and answers your question. It reads the code around the finding at the latest commit. Written as a new comment instead of a thread reply, it replies Ask for explain inside one of Gryndel's open finding threads.

ignore this

When: a finding is wrong, or right but deliberately accepted, and you don't want it raised again on this merge or pull request.

Reply in the finding's thread:

@gryndel ignore this

What happens: Gryndel replies Dismissed. Gryndel won't raise this finding again on this merge request. and resolves the thread. Later reviews of this merge or pull request leave it out; it shows in the review's Withheld list as Dismissed earlier on the merge request. Reports count it as Dismissed, a rejected finding, which tells your admins the finding wasn't useful.

Good to know:

• It applies to this merge or pull request only. To stop a kind of finding everywhere, ask an admin to adjust the rules or settings (see the guide to quietening noise).
• Gryndel recognises the finding by its file, line, category and title. If the code moves to another line, or a later review words the title differently, the finding can come back. Dismiss it again.
• It's worth adding a short reply saying why, for your colleagues.
• Outside an open Gryndel finding thread, Gryndel replies with how to use it instead.

resolve

When: you want to clear all of Gryndel's open threads at once, for example before merging when you've dealt with them yourself.

@gryndel resolve

What happens: Gryndel resolves all its open finding threads without checking them, and replies Resolved 3 Gryndel threads. Your colleagues' threads aren't touched. On GitHub, these are the review conversations Gryndel started; they show as resolved, just as if someone had clicked Resolve conversation.

Resolving counts as accepted

Reports count a resolved finding as Resolved, which means accepted. If findings were wrong, reply @gryndel ignore this in each, or react 👎, instead, so your acceptance numbers stay honest.

configuration

When: a review behaved differently from what you expected, such as the wrong review mode or a rule missing, and you want to see which setting applied and where it came from.

@gryndel configuration

What happens: Gryndel posts Gryndel configuration for this merge request: a table of every setting, its value, and which level set it: Gryndel's built-in defaults, the workspace's organization settings, a shared settings repository, the repository's settings in Gryndel, or the repository's .gryndel.yaml. The shared settings repository is usually called gryndel-config: a project in the GitLab group or a parent group, or on GitHub a repository of the account that owns the repository, such as your-org/gryndel-config. Locked settings show 🔒. It also lists the rules that apply, settings that weren't applied, and problems found in configuration files. Settings are read from the target branch (the branch the change will merge into). See How settings combine.

learn:

When: you notice something your team always wants checked, and Gryndel didn't flag it.

@gryndel learn: Log messages must not include customer email addresses, because logs are shipped to a third-party service.

What happens: Gryndel replies Got it, @you. Future reviews of this repository will follow this: with your text quoted. The text becomes an active rule for this repository at once, and appears under Learned on the Rules & learnings page, where an admin can edit it, add file patterns, or turn it off. Write it as you'd write any rule: specific, with the reason. See Teach a rule from a merge request.

With nothing after learn:, Gryndel asks what to remember.

help

@gryndel help

Gryndel posts a table of the commands. A comment with only @gryndel does the same.

Ask a question

Anything after @gryndel that isn't a command is a question about the merge or pull request. Gryndel answers using its title, description and changes, and its own live record of reviews on it. Asked in a finding's thread, the answer also takes that finding and its replies into account.

Good questions are specific and about this change:

@gryndel where is the review at? It's been 20 minutes.

@gryndel does this change affect the billing export?

@gryndel which callers of parse_token() need updating after this signature change?

@gryndel what would break if the cache returned stale data here?

In a finding's thread:

@gryndel would wrapping this in a transaction be enough to fix it?

Limits: Gryndel answers from the change and the description, not the whole repository, and never runs code. In a very large merge or pull request, some files' changes are left out of what it reads. If the answer isn't in what it can see, it says so rather than guessing. A question about review progress gets concrete steps and timings.

Common workflows

Fix a finding, then check it

1. Fix the code and push.
2. Gryndel reviews the new commit automatically, posts what's still wrong, and marks the old threads as outdated.
3. If you want a per-thread answer, or reviews are paused, comment @gryndel check.
4. Read Gryndel's reply in each thread still open, and fix what it says.

A finding is wrong

1. Reply in the thread with why, for example "The caller validates this in auth/middleware.py."
2. Then either:
   • reply @gryndel ignore this to dismiss it for this merge or pull request (recorded as Dismissed), or
   • react 👎 on the finding (recorded as Disputed) and resolve the thread yourself.
3. If the same mistake keeps coming up, tell a workspace admin, so they can tune the rules or settings.

@gryndel check would also resolve the thread if it accepts your reason, but Reports then count the finding as Resolved (accepted), not rejected.

Not sure whether a finding is right

1. Reply @gryndel explain in its thread, adding your doubt as a question.
2. If the explanation convinces you, fix it. If not, see A finding is wrong.

Review again after a settings change

An admin changed a rule or the model and you want this merge or pull request reviewed with it now: comment @gryndel review. Each review uses the settings in force when it was queued.

Lots of pushes on a work-in-progress branch

1. Comment @gryndel pause.
2. Push as often as you like.
3. When it's ready, comment @gryndel resume, then @gryndel review.

If Gryndel doesn't reply

Symptom	Cause	Fix
No reply at all	The comment doesn't start with @gryndel, or the repository isn't enrolled in Gryndel	Start the comment with @gryndel. Ask an admin whether the repository is turned on in Repositories.
No reply, in a repository that is reviewed	GitLab or GitHub couldn't deliver the comment to Gryndel	See Troubleshooting for checking webhook deliveries. On GitHub, the App's Advanced tab lists recent deliveries, with Redeliver.
No reply on GitHub, in a repository that is reviewed	Your Gryndel uses a different command word, or the comment is still pending in an unsubmitted review	Ask whoever runs Gryndel for the word; submit your review.
Sorry @you, Gryndel commands need the Developer role…	Your GitLab role is below Developer	Ask a Maintainer for Developer access, or ask a colleague.
Sorry @you, Gryndel commands need write access to this repository.	On GitHub you have read or triage access only	Ask a repository admin for write access, or ask a colleague.
A reply saying Gryndel is turned off	Reviews are off for the workspace, or for everyone	Ask a workspace admin.
Reply with ignore this inside one of Gryndel's open finding threads…	You wrote it as a new comment, or in a thread that's already resolved	Reply inside the open finding thread.
Only the 👀 reply, for a long time	Other requests are ahead, or the model is slow	Wait. Comment @gryndel status to see if a review is also running.
check did not work, with a reason	A model problem, such as an expired API key	Tell a workspace admin, who can fix it in Model settings.
A review started instead of an answer	The question began with a command word	Rephrase, starting with "what", "does" or "why".