Make Gryndel quieter and more accurate

Use this guide when people say Gryndel "comments too much" or "is usually wrong". There are two different problems behind those complaints, and they have different fixes:

• Too many comments: the findings may be right, but there are more than people want to read, such as suggestions and nitpicks on every merge request (GitLab) or pull request (GitHub).
• Too many wrong comments: findings that aren't real problems (false positives), or that are real but your team has decided not to care about.

Diagnose first, then change one thing at a time, so you can tell what helped.

Before you start: you can read everything as a viewer, but changing settings, rules and agents needs a workspace admin.

Step 1: find out what kind of noise it is

Look at Reports

Open Reports (sidebar, under MANAGE) and choose 30 days or 60 days.

1. In What people did with findings, look at Acceptance and the Rejected card. Rejected findings are ones people dismissed with @gryndel ignore this (Dismissed) or reacted 👎 to (Disputed).
2. In the Acceptance by table, switch between Repository, Severity, Category and Agent. Look for rows with many findings and low acceptance. That's where the noise comes from.
3. Under Usage, check By severity and By category: what Gryndel posts most.
4. In the Findings list, search for a noisy category or repository and open a few threads in GitLab or GitHub (the arrow at the end of each row). Read what people replied.

What you see	Most likely problem
Low acceptance across the board, many Disputed	Wrong findings: the model or review mode isn't accurate enough for your code.
Low acceptance for one Agent	That agent's prompt or model doesn't suit your code.
Low acceptance for one Category (for example style or performance)	Your team doesn't care about that kind of finding.
Low acceptance for P2 but fine for P0 and P1	Minor findings people don't want to see.
Many Left open	People ignore the comments without saying why. Ask them, and check the comment level.
Low acceptance in one Repository only	Something about that code: generated files, a different language, or missing rules.

Look at what Gryndel already held back

Gryndel doesn't post everything it considers. Held back by Gryndel on Reports counts the findings it dropped and why. For a single review, open it on Pull requests and look at the Withheld and Verification tabs. See Findings, Withheld and Verification.

This tells you whether the checks are working. If the verifier is already rejecting many candidates and the posted ones are still wrong, a stricter setting won't help much; a better model or prompt will.

note

In repositories set to Don't keep code, Gryndel keeps only each finding's title and location, so the review details show less. The summary note on the merge or pull request still lists the Withheld candidates for each review.

Step 2: fix it

Work down this table. The first rows are the quickest and safest.

Lever	Fixes	Where	Recommendation
Review mode	Wrong findings	Configure → Reviews	If you use Single pass, switch to Verified · draft and verify. Single pass posts what the model drafts without a second check.
Comment level	Too many suggestions and nitpicks	Configure → Findings	Agents mode only. Use 🤫 Whisper to post only verified issues, or 💬 Chat for at most three suggestions. Avoid 📣 Chatterbox unless people asked for it.
Min. severity to publish	Too many minor findings	Configure → Findings	P1 · high and critical removes P2 findings. Use P0 · critical only only for repositories where you want Gryndel nearly silent.
Excluded paths	Comments on code nobody writes by hand	Configure → Scope	Add generated code, vendored libraries, fixtures and snapshots, for example **/generated/** or tests/fixtures/**.
A rule that says what not to flag	A kind of finding your team has decided against	Rules & learnings	See below.
@gryndel ignore this	One wrong finding on one merge or pull request	The finding's thread in GitLab or GitHub	Dismisses it for that merge or pull request only.
Agent tuning	One agent is the noisy one	Review agents	See below.

Change settings in Repositories for one repository, or in Organization settings for all of them. Every change applies to reviews created after you save; reviews already queued keep their settings. To see the effect at once, comment @gryndel review on an open merge or pull request.

Severity: what each level drops

Severities are P0 (critical: security holes or data loss), P1 (realistic incorrect behaviour) and P2 (a minor real issue).

Min. severity to publish	Posted	Good for
P2 · all findings (default)	Everything	Pilots, and teams who want every real issue
P1 · high and critical	P0 and P1	Most teams after the pilot, if P2 findings are mostly waved away
P0 · critical only	P0 only	Repositories where only the worst problems are worth a comment

Findings below the threshold are listed as withheld with the reason severity policy, so you can still see them in the review details.

Rules that say what not to flag

Rules are instructions to the model, so you can use them to describe what your team does not want reported. Be specific, and give the reason:

Don't report missing input validation in internal/admin/ handlers. They are only reachable by staff behind the VPN and validated by the gateway.

In tests/, don't report hard-coded values, duplicated setup code or missing error handling. Tests are written for readability, not reuse.

A rule guides the model; it isn't a hard filter. If a whole folder should never be reviewed, use Excluded paths instead. To check the rule works, see Check that a rule works.

@gryndel ignore this

When a finding is wrong, a developer replies in its thread:

@gryndel ignore this

Gryndel resolves the thread and won't post that finding again on this merge or pull request, even after new commits. It counts as Dismissed on Reports, so dismissals are your best signal of what to tune. It doesn't affect other merge or pull requests. If the same kind of finding keeps being dismissed, turn it into a rule.

Tune or limit agents

In Agents mode, each review agent reports on its own area. Open Review agents (under MANAGE) and look at the Efficiency column: the share of an agent's findings that held up. An agent marked check prompt has been wrong more often than right.

Situation	Do this
An agent is often wrong	Edit its Prompt to say more precisely what to look for and what to leave alone. Its score starts fresh, so you can compare.
An agent is right but its findings shouldn't block	Untick May raise blocking issues. Its findings are posted as suggestions.
An agent doesn't fit one repository	In that repository's Configure → Reviews, tick only the agents it should use under Review agents.
An agent isn't useful anywhere	Untick Enabled for agent reviews.
An agent is fine on one model, poor on another	Give it its own prompt for that model, under Prompts and scores by model.

The Code structure agent only makes suggestions. If people find them noisy, a lower Comment level drops most of them without switching the agent off.

Step 3: check it helped

1. Note the date of your change.
2. After a week or two, open Reports and compare Acceptance for the repository, category or agent you changed. Choose a period that mostly covers the time after the change.
3. Read a few new merge or pull requests. Are the comments the ones people want?

If acceptance doesn't improve, the model itself may be the limit. Try a stronger model for the agents or the default provider in Model settings, and compare again.

If it didn't work

Problem	Cause	Fix
A setting didn't change anything	Reviews created before you saved keep their old settings	Comment @gryndel review to review again with the new settings.
The field shows 🔒 Locked by organization settings	Organization settings fix the value for every repository	Change it in Organization settings, or ask an admin there.
The repository ignores your setting	Its .gryndel.yaml sets a different value	Open Configure → Effective configuration → Preview to see which level set each value. See How settings combine.
Comment level made no difference	Comment level only applies in Agents mode	Use Min. severity to publish, or switch to Agents mode.
An excluded file still gets comments	The pattern doesn't match the path	Patterns start at the top of the repository. Start with **/ to match at any depth.