CtrlK
BlogDocsLog inGet started
Tessl Logo
PluginPublic

testland/sonarqube-rules

Use when a team runs SonarQube or SonarCloud for multi-language static analysis and code quality: sonar-scanner and sonar-project.properties, Sonar Way profiles and custom rules, quality gates on new code, branch and PR analysis, and NOSONAR or SuppressWarnings suppressions.

Quality

84%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide
SecuritybySnyk

Passed

No findings from the security scan

Overview
Quality
Evals
Security
Files

Quality

Content

75%Weight 40%Scale 1-5

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

A dense, command-driven reference with a clear 8-step sequence, concrete CI/API examples, and useful anti-patterns tied back to steps. Every dimension lands at 4 rather than 5 due to small headroom items: a few trimmable asides and version-sensitive details, non-executable steps for scanner install and Quality Gate thresholds, no explicit post-scan validation loop, and a slightly inconsistent References section.

Suggestions

Conciseness: drop the GitHub block-quote and the 'value over Semgrep' editorializing, and move version/date-sensitive details (LGPL→SSPL 2024, lts-community, action versions) into a dedicated 'Versions / deprecations' note so main sections stay evergreen.

Actionability: replace 'Download from docs → Analysis scanners. Place on PATH' with an executable download/unzip/PATH command, and add a one-line REST example with the authentication header since token generation is already documented.

Workflow clarity: add an explicit post-scan validation checkpoint after Step 5/7 (e.g., query /api/qualitygates/project_status and act on FAIL before merging) so the sequence has a closed feedback loop rather than relying on the CI action alone.

DimensionReasoningScore

Conciseness

The body is dominated by executable artifacts (docker run, sonar-scanner flags, a full sonar-project.properties, CI YAML, REST API table) with little padding. Minor over-explanation that could be trimmed: the Overview's GitHub quote ("SonarQube provides the capability to not only show the health of an application...") and editorial asides like "the audit trail is the value over Semgrep's per-comment approach". Not 5 because these few tokens don't earn their place, and version/date-sensitive details ("License changed from LGPL to SSPL in 2024", "sonarqube:lts-community", "actions/checkout@v5") sit in main sections rather than a deprecated/old-patterns section; well above anchor 3's 'several unnecessary explanations'.

4 / 5

Actionability

Mostly copy-paste-ready: the scanner invocation with -Dsonar.* flags, the complete sonar-project.properties, PR analysis flags, the GitHub Actions YAML, and concrete REST endpoints ("GET /api/issues/search?projectKeys=...", "POST /api/issues/do_transition"). Not 5 due to gaps such as "Download from [docs] → 'Analysis scanners'. Place on PATH" (no executable command) and the placeholder thresholds "Coverage on New Code ≥ X%"; the Quality Gate and Step 1/2 sections rely on UI navigation ("consult your SonarQube UI at Quality Gates → Sonar Way") rather than commands.

4 / 5

Workflow Clarity

Steps 1-8 give a clear install → scan → configure → gate → CI → API sequence, and the Anti-patterns table cross-references fixes back to steps ("Always fetch-depth: 0 (Step 7)"). Checkpoints are partially present: "sonar.qualitygate.wait=true makes the scanner block until the gate decision is computed - critical for CI gating" and the quality-gate-action with timeout. Not 5 because there is no explicit validate-and-fix loop (e.g., check gate/issue output after a scan and react); not 3 because the gate-wait and quality-gate-action steps function as embedded checkpoints and the batch-triage risk is explicitly guarded ("Mass-resolve as FP without review → Require comment + reviewer attribution").

4 / 5

Progressive Disclosure

No bundle files exist (references/, scripts/, assets/ are absent), so all content is inline in a single well-sectioned SKILL.md with clear headers and a closing References section. The inline material is appropriately overview-length (no 100+ line walls), and references are one level deep (docs URLs and sister skills). Not 5 because it exceeds the under-50-line simple-skill exception, and the References section mixes markdown links ("[sq-gh][sq-gh] - repository") with bare URLs and unresolvable skill names ("`semgrep-rules`, `codeql-queries`, `language-native-sast` - sister scanners"), a minor organization gap.

4 / 5

Total

16

/

20

Passed

Description

86%Weight 40%Scale 1-5

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

A strong, dense description with an explicit 'Use when...' trigger, third-person voice, and comprehensive natural trigger terms including product synonyms and exact tool/file names. The only weakness is that the 'what' is expressed as a list of topic nouns rather than concrete actions, which keeps specificity and completeness at 4.

DimensionReasoningScore

Specificity

Quotes: "sonar-scanner and sonar-project.properties, Sonar Way profiles and custom rules, quality gates on new code, branch and PR analysis, and NOSONAR or SuppressWarnings suppressions" — several specific, concrete items covering the skill's surface. Not 5 because these are config entities and topic nouns rather than concrete actions (no verbs like 'configure', 'triage', or 'set up'), and body topics such as CI integration and the REST API are absent; not 3 because coverage goes well beyond 1-2 items and is domain-precise.

4 / 5

Completeness

Quote: "Use when a team runs SonarQube or SonarCloud for multi-language static analysis and code quality: ..." — an explicit 'when' clause plus a 'what' delivered as a colon-separated topic list. Not 5 because the 'what' enumerates subjects the skill touches without stating what the skill does with them (e.g., configure, gate CI, triage issues); clearly above anchor 3 since 'when' is explicit, not merely implied.

4 / 5

Trigger Term Quality

Quotes: "SonarQube or SonarCloud", "sonar-scanner", "sonar-project.properties", "quality gates on new code", "branch and PR analysis", "NOSONAR or SuppressWarnings" — comprehensive natural-term coverage including product synonyms and exact tool/file names users would say. Matches the anchor-5 pattern (synonyms plus concrete file/tool identifiers) rather than anchor 4, which is reserved for coverage with clearly missing common terms.

5 / 5

Distinctiveness Conflict Risk

Quotes: "SonarQube or SonarCloud", "Sonar Way profiles", "sonar-scanner" — a clear niche anchored in product-specific names that competing skills (semgrep, codeql) would not match. Minimal conflict risk; rival tools are not named in the description, so it will not trigger for the wrong skill.

5 / 5

Total

18

/

20

Passed

Validation

100%

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Reviewed

On this page