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.
Pack dev-teamTier standardJob Build and review softwarev0.1.0
In Claude Code, with the dev-team plugin installed, invoke it as:
/dev-team:sonar-review
Try it
A realistic prompt from the skill's acceptance evals:
Run a Sonar review on my current branch before I open the PR.
What a good result looks like
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.
How it's checked
Measured against plain Claude Code (2026-10-23): it met 52% of its checks, against 52% without it, and a blind judge preferred it. How skills are checked
18 assertions across 3 acceptance evals, and 8 trigger queries. Every skill's checks
What the output must do
The verdict is taken from the quality gate itself, not from the reviewer's own judgment — PASS is reported as PASS even if other issues are visible
Findings are scoped to files changed on the branch; pre-existing repo debt is not dumped into the report
Findings are severity-tagged and each carries file:line, the Sonar rule ID, why it matters, and a concrete fix
Findings are grouped into the lenses (bugs, vulnerabilities, security hotspots, code smells, coverage/duplication)
Server vs cloud is auto-detected from sonar-project.properties rather than assumed
Reports that the gate fails, taking the verdict from the status in quality-gate.json, and names at least the new-code coverage condition (61.3% against 80%) and the unreviewed security hotspot condition
Explains that the local 85% figure does not change the result: the gate measured 61.3% coverage on new code
Keeps the findings to the changed files: the blocker SQL-injection issue in legacy/ledger_import.py and the issue in intake/weighbridge.py are not presented as findings for this branch (they may be noted separately as pre-existing)
Does not list the issue resolved as a false positive (python:S1192 in intake/payments.py) as an open finding
Notes that the scan analysed revision 7f3c2e1 while the branch head is 9a41d07, whose commit message suggests the float-comparison bug was fixed after the scan, so the results may be out of date
Does not invent issues, rule IDs, line numbers or metric values that are not in the supplied files, and does not claim to have run a new scan
Stays under 300 words
Gives a clear recommendation for Friday: this change should not go out until the gate passes, unless someone decides on purpose to accept the risk
Explains in plain words that the failures are about too little testing of the new code and too much copied code, and that no new bugs or security problems were reported
Does not describe the result as a security or data-loss problem
Does not invent files, rule IDs, specific issues or figures beyond the text on the screen, and does not claim to have run a scan
Uses at most three sentences
Answers without first asking for access, a token or more information
When it should and shouldn't activate
Should activate:
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
Should leave to another skill:
Set up Sonar in this repository
Review this code adversarially for edge cases the first pass missed