Skip to content
cccskills
FreePublished on GitHub

sonar-loop

Drive a PR to a green quality gate and keep it there. Loops on SonarCloud for the project's targets, no new issues, no duplication on new code, and coverage on new logic as close to 100% as the code allows, then watches the PR checks until every one passes. Use when a quality gate blocks a merge, when coverage or duplication has to come up, or before asking for review. Triggers - "fix the sonar issues", "quality gate", "get coverage up", "zero duplication", "loop until CI is green", "watch the checks".

The English summary is being prepared. Showing the original description.

Works withGitHub
See how to install

Files included (1)

  • SKILL.md4.8 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

Sonar loop

The targets are the project's, not this skill's. Find them before deciding anything, in the conventions doc or the contributing guide, and treat them as part of done rather than as a follow-up. A common bar, and a good default when a project states none: 0 new issues, 0% duplication on new code, near-total coverage on new logic.

Read sonar-project.properties before calling anything a false positive. It holds the scanner's scope, the coverage denominator, and every reviewed suppression. A project with no such file is not scanned by Sonar, so skip to the checks loop and use whatever gate its CI runs.

Run the gate locally first

Cheaper than a round trip through CI, and it catches most of it. Read the manifest scripts for the project's wrappers; the ones that matter are a changed-files precheck, the formatter and linter, and the coverage run:

<precheck script>     # the changed files, against the rules that usually fire
<lint script>         # formatter and linter
<coverage script>     # writes lcov for the scanner

Note where each coverage report lands. Per-language reports go in different places and the scanner needs every path listed in its properties file, so a new language in the repo means a new entry there.

Getting a token

Everything below needs SONAR_TOKEN. In CI it is a repository secret. Locally it is not set, and the first curl fails with nothing useful printed, so check before looping:

[ -n "$SONAR_TOKEN" ] || echo 'no SONAR_TOKEN: generate one under My Account > Security on sonarcloud.io'

Without a token, read the gate through the PR's own check output (gh pr checks, gh run view --log) instead. That is slower but needs no credential, and it is the right path in an unattended run.

The loop

  1. Read the current state. Measures first, so you fix the thing that is actually failing:
PR=<number>
KEY=$(grep sonar.projectKey sonar-project.properties | cut -d= -f2 | tr -d ' ')
curl -fsSL -u "${SONAR_TOKEN}:" \
  "https://sonarcloud.io/api/measures/component?component=${KEY}&pullRequest=${PR}&metricKeys=new_violations,new_coverage,new_duplicated_lines_density,new_security_hotspots" \
  | jq -r '.component.measures[] | "\(.metric)=\(.period.value // .value)"'

The quality-gate endpoint carries numbers the measures endpoint returns as null, so fall back to /api/qualitygates/project_status?pullRequest=${PR}&projectKey=${KEY} when a value is missing.

  1. Take the offenders one at a time, worst first. One cause per commit.
  2. Push, then wait for the rescan rather than guessing:
gh pr checks $PR --watch --fail-fast
  1. Re-read the measures. The check set can change between runs, so re-read it rather than assuming the previous list still holds.
  2. Stop when every target is met and every check is green.

Fixing, in order of preference

Coverage. Untested new logic is the usual gap, and the usual cause is logic that landed somewhere a test cannot reach. Move it rather than excluding it: new logic goes where a test can call it. Use the project's test skills to write the test, and tdd when the code is not written yet.

Two traps that make a local number lie. A coverage tool that instruments only what the tests loaded reads far higher than Sonar, which counts every file in scope, so a file no test imports is invisible locally and a zero in the gate. And a branch the runner cannot take, a require() fallback or a build-time environment check, is covered on paper by a test that asserts nothing.

Duplication. Extract the shared thing into a real home and have both callers reach it by name. Copying a block and renaming a variable is what put it there.

Issues. Prefer a code fix over a suppression, every time. When a rule is genuinely wrong for a line, the entry goes in sonar-project.properties where a reviewer sees it, with the reason. Never an inline NOSONAR.

Failures that are not yours

If a check fails for a reason the PR did not cause and the default branch is green, merge the default branch in rather than bloating the PR with an unrelated fix. If a check is flaky, retry once and say so with the evidence. Never bypass the hooks or force a merge.

Report

Current numbers against each target, what was fixed and why, anything suppressed and the reason, and the PR URL once it is green.

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

One file, one job, and short enough to hold in your head. Covers the size policy (hard-split over 300 lines, split 200 to 300 at a seam, aim for 150), what a natural seam is and where to cut, the exemptions, the dependency rules that decide where the split lands, and the signals that a file is already two files. Use before adding to a file that is already long, when naming a new file, when a function has nowhere obvious to live, or when a review says a file is doing too much. Triggers - "this file is too long", "where should this go", "split this file", "is this file too big", "one responsibility".

The English summary is being prepared. Showing the original description.

kromatv/kroma62Updated Oct 20, 2026

naming

Free

What things get called. A file is named after its export in the project's case convention, a suffix is a resolution instruction rather than decoration, an index file only re-exports, and some symbol names are always wrong (utils, helpers, V2, Enhanced, New). Covers learning a tree's local vocabulary before adding to it, test and platform-variant naming, and the per-language conventions. Use when creating a file or directory, naming a test file, adding a platform variant, or when a name has to change. Triggers - "what should I call this file", "where does this file go", "naming convention", "kebab or camel", "name this test".

The English summary is being prepared. Showing the original description.

kromatv/kroma62Updated Oct 20, 2026

Spawn the comment hunter, fix accepted findings, and offer encodings for claimed constraints.

The English summary is being prepared. Showing the original description.

kromatv/kroma62Updated Oct 20, 2026

Write a short release note people finish reading. Picks the few changes a user will notice from the pull requests since the last release, names each by what the reader can now do, keeps to a length budget, writes every language from the intent instead of translating, and traces every line to a PR. Use when cutting a release, or filling a GitHub Release body, a store "what's new", a package changelog or an in-app what's new screen. Triggers - "write the release notes", "release notes for 0.4.0", "what's new", "changelog for this release", "notes de version".

The English summary is being prepared. Showing the original description.

kromatv/kroma62Updated Oct 20, 2026

Rust best practices. Use when reading or editing any .rs file, designing a crate's public API, choosing an error type, splitting a workspace, or writing async code on tokio. Triggers - "rust best practices", "is this idiomatic", "should this be a newtype", "anyhow or thiserror", "why does the borrow checker", "review this Rust".

The English summary is being prepared. Showing the original description.

kromatv/kroma62Updated Oct 20, 2026

Write cargo tests. A test name is a sentence, the body is setup, mock, test and verify blocks separated by blank lines with no comments, and shared setup lives in a named test-support module rather than in each test. Covers naming, the block shape, where a test file goes, async and time, workspaces, and running one crate or one filter. Use when adding or changing any #[test] or #[tokio::test], or when Rust coverage has to come up. Triggers - "write a rust test", "cargo test", "test this crate", "cover this handler".

The English summary is being prepared. Showing the original description.

kromatv/kroma62Updated Oct 20, 2026

See all skills by kromatv

Report a problem with this skill