Use sonar-onboard

Scaffold a repo for Sonar compliance

Scaffold a repo for Sonar compliance — supports both SonarQube server (self-hosted) and SonarCloud (SaaS), user picks at setup time. Generates sonar-project.properties with language-correct source/test/coverage paths, a CI workflow that runs the scanner on every push and PR and blocks merge on quality-gate failure, and a README snippet documenting the gate. One-shot setup; pair with sonar-review for per-change feedback.

Reach for it when the user says "set up Sonar", "add SonarQube to this repo", "wire up SonarCloud", "set up the quality gate", or asks to make a project Sonar-compliant for the first time.

Install it

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

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

Ask for it

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

• "Set up Sonar for this repo"
• "Scaffold sonar-project.properties and the CI workflow"
• "Onboard this project onto SonarCloud with a blocking quality gate"
• "We want Sonar checks on every PR — configure it"

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

• "Run the Sonar scan and tell me if the gate passes"
• "Adversarially review this diff for edge cases"
• "Gate my change with lint, tests, and the reviewer panel"

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

Check what you get

A good result:

• Properties file is keyed to the actual repo. sonar.projectKey, sonar.sources, sonar.tests, and the coverage path must reflect what's on disk — not a generic example. A properties file that scans the wrong directories produces a green gate that means nothing.
• The workflow blocks merge on gate failure. A scan that runs but doesn't fail PRs is decoration. The sonarqube-quality-gate-action step is non-negotiable.
• Coverage path exists or is marked TODO. Pointing at a coverage file that the test step never produces gives Sonar 0% coverage and a false-failing gate. Either wire it up end-to-end or leave it explicit.
• fetch-depth: 0 in checkout. Shallow clones break Sonar's new-code-period detection. The first scan will look fine; the next ten PRs will mis-attribute issues.
• Secrets are referenced, never inlined. No raw tokens or URLs in committed files. The token belongs in GitHub Secrets; the URL too, even though it's not technically secret — it keeps fork PRs from leaking the host.
• README snippet tells the next contributor what the gate enforces. "Sonar must pass" is not enough — list the conditions (no new bugs, no new vulnerabilities, coverage on new code ≥ X%, duplication ≤ Y%).

Use something else when

• Repo already has a working sonar-project.properties and a CI workflow that runs the scanner. Use sonar-review for per-change feedback instead.
• User wants to disable rules or relax the gate to make a failing scan pass. That's a code-quality conversation, not a setup task — push back.
• User wants language-specific deep config (custom rule profiles, Sonar plugins, branch analysis tuning). Out of scope; point at reference.md and the Sonar docs.
• User wants both SonarQube server and SonarCloud scanning the same repo. Pick one — running both means two gates, two histories, and two answers to "did the build pass?".

Next

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

Edit this page on GitHub · View source