| name | sonarqube-ai-slop-gate |
| description | Corrects the wrong defaults a model has when standing up self-hosted SonarQube Server as a continuous gate on AI-generated code, verified against docs.sonarsource.com in July 2026 (Server 2026.3, LTA 2026.1). Use when configuring SonarQube, designing a quality gate, or wiring a scan step into CI for AI-assisted work. Covers the setups that run green while measuring almost nothing — the fudge factor skips duplication and coverage conditions below 20 new lines and is on by default; duplication is never measured on test code; no `new_cognitive_complexity` metric exists to gate on; `sonar.host.url` now defaults to sonarcloud.io rather than localhost; a shallow clone degrades new-code attribution to timestamps. Also covers AI Code Assurance — the project flag, gate qualification, the deprecated Copilot autodetection — and that Community Build cannot analyze pull requests at all. NOT for SonarQube Cloud, IDE connected mode, or authoring custom analyzer rules. |
SonarQube AI Slop Gate
The decisions self-hosted SonarQube forces when you use it to gate AI-generated code, and how to settle them. Every rule names the wrong default it corrects; there is no rule for what the model already gets right.
Pinned to a date, not a version. SonarQube ships a release every two months, so every claim here was verified against docs.sonarsource.com in July 2026, against SonarQube Server 2026.3 (current LTA 2026.1). 2026.4 had shipped at the time of writing but the documentation still defaulted to 2026.3, so that is what these rules describe — plat-versions-are-calendar-based covers the release train itself. Re-verify anything version-shaped before trusting it, and read docs from the unversioned path (/latest/<page> does not resolve); appending .md to any docs URL returns its markdown source.
The failure this skill exists to prevent is a gate that passes everything. A SonarQube setup assembled from 2024-vintage knowledge will analyze the wrong branch, upload to the wrong server, exit green on a red gate, and skip the duplication and coverage conditions entirely on the small commits that AI-assisted work produces most of. None of those failures announce themselves; the dashboard looks healthy throughout.
When to Apply
Use this skill when:
- Standing up self-hosted SonarQube Server, or reviewing an existing instance, with the goal of catching AI-generated defects continuously rather than reporting on them after the fact
- Designing or tightening a quality gate — especially deciding what to measure on new code versus overall code, and discovering which conditions are silently not evaluated
- Wiring a scan step into CI: scanner properties, tokens, branch and pull-request parameters, coverage report import, or making the pipeline actually block a merge
- Setting up AI Code Assurance — flagging projects, qualifying a gate, or working out why a project reports "AI Code Assurance is off"
- A gate passes changes that obviously contain duplicated or untested generated code, and nobody can explain why
This skill is NOT for:
- SonarQube Cloud — the edition boundaries, token model, and several AI features differ; the agentic-AI gate in particular is documented for Cloud only
- IDE connected mode, SonarLint, or the SonarQube CLI's local agentic analysis
- Authoring custom analyzer rules or plugins — this covers configuring the rules that ship, not writing new ones
- General code-review judgement about whether code is good; this is about making the tool measure what you think it measures
Rule Categories
| # | Category | Prefix | Covers |
|---|
| 1 | Edition & Version Reality | plat- | What your licence can do; CalVer and the LTA upgrade path; which AI features need which edition |
| 2 | AI Code Assurance | aica- | The project flag, gate qualification, deprecated autodetection, the agentic profile |
| 3 | What the Gate Doesn't Measure | blind- | Suppression comments, fudge factor, test-code exemption, missing metrics, PR blind spots |
| 4 | New Code & Blame | newcode- | Full-clone requirement; choosing a definition that matches the branching model |
| 5 | Scanner Configuration | scan- | The properties whose defaults fail open — host URL, gate wait, test scope, coverage, exclusions |
| 6 | Running the Server | ops- | Kernel limits before first boot; database and volumes that survive an upgrade |
Quick Reference
1. Edition & Version Reality
2. AI Code Assurance
3. What the Gate Doesn't Measure
4. New Code & Blame
5. Scanner Configuration
6. Running the Server
Suggested Order
Categories are listed by importance — a mistake in category 1 invalidates the whole plan, a mistake in category 6 fails loudly at boot. That is not the order you execute in. For a fresh setup, work through them as:
1 → 6 → 5 → 4 → 2 → 3. Confirm the licence can do what you need, stand up the server, configure the scanner, define what "new" means, apply the AI Code Assurance machinery, and read category 3 last — before declaring the gate finished, because it is the list of reasons a green verdict may be meaningless.
How to Use
Read a reference file when its decision comes up. Each rule names the wrong default it corrects, then shows the canonical configuration.
