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. Use 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.
Pack dev-teamTier lightJob Build and review softwarev0.1.0
In Claude Code, with the dev-team plugin installed, invoke it as:
/dev-team:sonar-onboard
Try it
A realistic prompt from the skill's acceptance evals:
Set this Python repo up for Sonar compliance — we use SonarCloud and run CI on GitHub Actions.
What a good result looks like
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%).
How it's checked
Measured against plain Claude Code (2026-10-23): it met 87% of its checks, against 67% 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
sonar.projectKey, sonar.sources, sonar.tests and the coverage path reflect what is actually on disk, not generic example values
The generated CI workflow blocks merge on a quality-gate failure rather than merely running a scan
SonarCloud vs SonarQube server is chosen explicitly and the generated config matches that choice
The coverage report path matches the language's real tooling output
Setup steps that require a token or server-side action are named for the operator rather than silently assumed
Writes a sonar-project.properties aimed at the self-hosted SonarQube server from the prompt, with no SonarCloud organisation setting
Analysis covers both the Python package under src/wayline (tests in tests/) and the TypeScript frontend under web/src, with the *.test.ts files treated as tests rather than sources, and excludes the generated src/wayline/_generated and the vendored src/wayline/vendor code
The Python coverage report path is build/coverage.xml, which the GitLab test job writes through its --cov-report flag (not the reports/coverage.xml default in pyproject.toml), and the TypeScript path is web/coverage/lcov.info
The scan is added to .gitlab-ci.yml, the active CI, rather than the deprecated GitHub Actions workflow; the existing jobs are kept and the pipeline fails when the quality gate fails
Says that the 90%-coverage-on-new-code condition is set on the quality gate in SonarQube itself (by someone with admin rights there), not in repository files, rather than implying a properties setting enforces it
No token value, server address or organisation appears that is not in the input; the token is read only from the SONAR_TOKEN CI variable
The README section is under 15 lines
Writes the configuration files (a Sonar properties file and a GitHub Actions workflow, or equivalent) into the working folder rather than only describing them or asking questions
Targets SonarCloud, as the user indicated, not a self-hosted server
Values it cannot know, such as the SonarCloud organisation and project key, are clearly marked as placeholders the user must fill in
Does not configure a test or coverage report path, since the site has no tests, and does not invent other project details
Tells the user the steps they must do themselves, such as importing the project on SonarCloud and adding the token as a GitHub repository secret, and puts no token in any file
The explanation is a few short lines in plain language, not a long tutorial
When it should and shouldn't activate
Should activate:
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
Should leave to another skill:
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