Use sonar-review

Run a Sonar scan against the just-changed code on the current branch and produce a structured compliance report

Run a Sonar scan against the just-changed code on the current branch and produce a structured compliance report — quality-gate verdict (PASS / FAIL), then severity-tagged findings (🟥 blocker / 🟧 critical / 🟨 major / ⚪ minor / ⚪ info) scoped to changed files, each with file:line, the Sonar rule ID, the category (bug / vulnerability / security hotspot / code smell), why it matters, and a concrete fix. Works against both SonarQube server (self-hosted) and SonarCloud (SaaS) — mode is detected from sonar-project.properties. Sister skill to devils-advocate, but enforces Sonar's rule catalog and the project's quality gate rather than a hand-rolled lens sweep. Use after writing code, before pushing or opening a PR, when the user says "is this Sonar-compliant?", "run Sonar on this", "will the quality gate pass?", or any pre-merge compliance check.

Install it

npx skilldrop-cli install sonar-review                 # Claude Code, your user folder
npx skilldrop-cli install sonar-review --project       # Claude Code, this repo
npx skilldrop-cli install sonar-review --ide cursor    # or kiro, codex, antigravity, copilot

It is part of the Dev team pack: --pack dev-team installs it with its neighbours.

It needs SONAR_TOKEN set in the environment.

Ask for it

Say it the way you would to a colleague. Requests like these route to it:

• "Run a Sonar review on this branch"
• "What does the quality gate say about my changes?"
• "Give me the Sonar findings for the files I changed"
• "Check Sonar compliance before I open the PR"

Requests like these belong to a different skill, so it shouldn't answer them:

• "Set up Sonar in this repository"
• "Review this code adversarially for edge cases the first pass missed"
• "Run the full pre-merge gate and reviewer panel"

If another skill answers instead, ask for this one by name: "use sonar-review".

Check what you get

A good result:

• Verdict comes from the gate, not from you. The quality gate is the source of truth. ✅ "Gate FAIL — 1 new vulnerability." ❌ "Looks risky to me." If the gate passed, say PASS even if you'd personally flag issues.
• Findings are scoped to changed files. The repo has pre-existing debt; this skill is a pre-merge check, not a backlog dump. Pre-existing issues in touched files go in a separate "FYI" section — issues in untouched files don't appear at all.
• Every finding cites file:line and the Sonar rule ID. javascript:S2228 is a click-through to the Sonar UI catalog. Strip either and the finding becomes unactionable.
• Severity is Sonar's, not yours. Don't downgrade a CRITICAL because you disagree, and don't upgrade a MINOR to make the report scarier. If you disagree with the catalog, raise it in the lens body, don't rewrite the severity.
• Fixes name a concrete change. A patch line, a function rename, a missing test case — not "consider refactoring".
• Don't recommend disabling rules to pass the gate. That's a code-quality conversation. Suggest fixes or scoping (Sonar-scoping comments like // NOSONAR should be rare and justified in the code, not as a default).
• Security hotspots are flagged for review, not "fixed". Hotspots ask "is this safe?" — the resolution is a human decision (mark Safe, At Risk, Acknowledged). The fix you write is the evidence the user needs to make that call, not a code patch.

Use something else when

• Repo isn't set up for Sonar (no sonar-project.properties). Run sonar-onboard first.
• User wants a code review broader than Sonar's catalog covers (architecture, idiomatic concerns, test-design). Use devils-advocate instead — different lens.
• User wants to fix the whole codebase's Sonar debt. This skill is per-change; for a debt-paydown plan, query the Sonar UI directly.
• Repo only has linters (ESLint, Pylint, golangci-lint) and no Sonar. Different tool, different catalog — running this skill would produce nothing.
• Repo isn't wired to either SonarQube server or SonarCloud — no sonar-project.properties means there's nothing to scan against. Run sonar-onboard first.

Next

• SKILL.md, the instructions the agent reads
• Its page on the site
• Related: devils-advocate, sonar-onboard

Edit this page on GitHub · View source