Agents write plausible code fast, and some of it takes shortcuts a careful engineer would not: a test skipped to get green, an error swallowed, a stub left in, a type check silenced, a second way of doing what your codebase already does. The anti-slop check looks for these in every change and sends the change back to the developer agent before you see it.
It is one check in your quality policy, not a separate score. A change passes it when it introduces nothing that blocks.
What it looks for
Rules are grouped into families. Each rule either blocks, advises or records info.
- Tests — focused or skipped tests, deleted tests, removed or weakened assertions, tests that cannot fail.
- Suppressions — new lint disables, type ignores and
anycasts. - Build and CI — test steps removed or neutralised, thresholds lowered, "pass with no tests".
- Test evidence — cached results passed off as a run, zero tests executed, a partial run reported as complete.
- Production code — debug leftovers, placeholders, mock data, notes to humans, test code shipped.
- Error handling — swallowed errors, fallbacks that hide failures, fail-open permission checks.
- Comments, Architecture, Dependencies, Change scope, Security, Caching and the agent trail — the record of what the agent did, such as editing a test right after it failed.
Each rule's page in Quality → Checks → Anti-slop shows what it matches and why it matters.
Only what the change introduced blocks
Most repositories already contain some of these patterns. Anti-slop sorts every finding into one of three groups:
- Introduced — new in this change.
- Touched — already there, on a line or in a function the change edits.
- Existing — elsewhere in the repository.
Only an introduced finding of a blocking rule fails the check. Touched and existing findings are recorded so you can see your debt, but they never hold up unrelated work. Moving code does not count as introducing it; copying it does.
Raised
- An advisory gate
The reviewer agent
- A connected scanner
Routed
Fixable
Back to the developer as rework
Everything else
Attached to the pull request
Resolved
Fixed
The change addresses it
Accepted
True, not worth acting on here. Say why.
Suppressed
A false positive or rule that does not apply. Say why.
Adding it to a policy
Open a policy in Quality → Policies and choose Add anti-slop preset. It adds five expectations:
- Tests still prove the change.
- Nothing unfinished or test-only ships.
- No new structural debt.
- The change stays in scope and reads like this codebase.
- New dependencies are real and reputable.
Publish the policy, and the next run of each attached project includes the check.
Choosing a change discipline
The discipline tells the developer agent how far a change may reach:
- Surgical — only what the specification needs; other problems are reported, not fixed.
- Balanced (default) — also fix small problems on lines the change touches anyway.
- Restorative — also clean up findings inside the functions the change edits.
The agent works to the same rules before it submits: it gets the discipline and your quarantined patterns up front, sees the fast rules after every edit, and gets one chance to fix blocking findings before QA.
Making it fit your codebase
- Rule overrides — turn a rule off, or make it advise instead of block, in the check's settings.
- Rule packs — your own patterns, forbidden imports and dependencies, file size limits, or results from tools you already run (SARIF). Packs are versioned; a policy pins the version it uses.
- Quarantine — patterns you do not want copied any more, each with the replacement to use instead. Agents are told not to spread them, and new copies are flagged.
- Repository file —
.coroid/anti-slop.ymlin the repository can add rules and exclude generated or vendored paths. It is read from the base of the change, so a change cannot loosen its own rules, and editing it needs approval.
Findings and waivers
Findings appear in Quality → Findings, filtered by check. To accept one, waive it with a reason; the waiver is recorded against that exact finding. Agents cannot waive their own findings. When an agent says a test was wrong and changes it, a reviewer must approve that change before the check passes.
Judge rules
Two rules ask a model, one line at a time: a defensive check for something the code shown makes impossible, and a comment that contradicts the code next to it. They only advise, never block. Enable judge rules is on for a new check, with a per-run limit of decisions; turn it off in the check's settings.
Your own agents
The same rules can guide agents you run yourself:
- Download AGENTS.md snippet, on the Debt tab of Quality → Checks → Anti-slop, gives a project's change discipline, quarantine and top rules as a section to paste into your agents' instructions.
- Through the Coroid MCP server,
anti_slop_rulesdescribes your published policy andanti_slop_scanscans a branch of a synced project, read-only.