sonar-sweep

The ask has one shape: a SonarCloud number the user saw on the PR ("fix the 47 new sonarcloud issues") and an order to make it zero without breaking anything. This skill does it with gh plus the SonarCloud API, no plugin needed.

Read first

• Your user-level rules (honesty and verification, editing files)
• Feature vs gate: quality gates are a cleanup phase paid back in bulk, not a build phase. On a feature turn where the user has not named Sonar, this skill does not run.
• The repo's sonar-project.properties or .sonarcloud.properties (automatic analysis vs a scan step in a workflow) and its CLAUDE.md quality rules

Procedure

1. Resolve the project key, in order: sonar.projectKey in the properties file; the SonarCloud check run on the PR head (gh api repos/<owner>/<repo>/commits/<sha>/check-runs --jq '.check_runs[] | select(.name | test("Sonar")) | .details_url', the URL carries id=<key> and pullRequest=<n>); else <owner>_<repo>, the default for GitHub-imported projects. The organization key is usually the lowercased GitHub owner.
2. Enumerate, print, then edit. Public projects need no token; a private one takes -H "Authorization: Bearer $SONAR_TOKEN" with the value never echoed: curl -s "https://sonarcloud.io/api/issues/search?componentKeys=<key>&resolved=false&ps=500&facets=rules,severities,types" Add &pullRequest=<n> for PR-new issues; omit it for main. Then the gate: curl -s "https://sonarcloud.io/api/qualitygates/project_status?projectKey=<key>&pullRequest=<n>" Print the total, count per rule id, count per severity, and the failing gate condition. That total is the denominator for the rest of the session. A gate can fail with 0 issues: check new_duplicated_lines_density too (copied test fixtures count as duplication).
3. Work by rule id, not by file: one rule has one mechanical fix, applied across every occurrence before the next rule.

4. Preserve line endings (no sed -i on CRLF repos), no formatter over untouched files. Every changed line traces to an issue in the list; if not, revert it.
5. Verify once at the end, not per file: the repo's own lane (a single pnpm run check if it has one; else pnpm run lint then pnpm run typecheck, or uv run ruff check . then uv run mypy) plus the tests covering the touched files. A red lane means step 4 changed behavior; fix that first.
6. Push to the existing PR branch (never a second PR), wait for the SonarCloud check (gh pr checks <n> --watch), re-run step 2 with the same parameters. The API total is the proof: 47 -> 0 from issues/search, not from the diff.
7. Whatever remains is a false positive or out of scope. List each by rule id, file:line, and one line why. Do not resolve it in SonarCloud; the user decides.
8. If the same message said "merge it", hand to ship with the count table.

Output

| scope | before | fixed | left | proof |
| PR #N new | 47 | 47 | 0 | issues/search total=0 at 2026-09-22T10:02:11Z |
| main inherited | 12 | 9 | 3 | issues/search total=3 |

by rule: S3776 14/14, S3358 9/9, S1192 20/20, S6582 4/4
false positives (left unresolved in SonarCloud): S1192 src/x.ts:41 test fixture literal
gate: passed / failed on <condition>
lane: pnpm run check pass | tests 212/212

Must not

• Never mark an issue won't-fix, false positive, or resolved in SonarCloud; the count drops only because code changed.
• Never disable or exclude a rule in sonar-project.properties, .sonarcloud.properties, ESLint, or ruff config; never add // NOSONAR or # noqa to make a finding vanish.
• Never remove a feature, a UI element, a test, or a log line to satisfy a rule.
• Never reformat, re-order imports, or "clean up" a file with no finding.
• Never report "fixed the sonar issues"; only fixed N/M with the API total.
• Never run on a feature turn: "not sonar, just focus on the UI" ends this skill at once; note the count for later.
• Never echo SONAR_TOKEN or any credential value in a command or the reply.
• Never chain commands with a double ampersand; one per line.

Non-goals

Other red CI checks (gh-actions), reviewer and Copilot comments and Dependabot alerts (fix-all, which calls this for its Sonar lane), merging (ship), structural refactors beyond the finding (a clean-code skill, if installed).