CtrlK
BlogDocsLog inGet started
Tessl Logo

testland/sonarqube-maintainability-gate

Run SonarQube/SonarCloud against production code to surface Code Smells, Bugs, and Maintainability ratings - the maintainability lens rather than the security lens. Production-only scope via sonar.exclusions; test code is reviewed separately. Use when a team wants maintainability and technical-debt ratings gating PRs, or when an existing SonarQube project reports numbers nobody has tied to a quality gate.

73

Quality

92%

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

88%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 tight, highly actionable operational runbook: exact commands and config for each stack, a metric table tied to gate defaults, and an anti-patterns table covering real failure modes. The only weaknesses are minor: a slightly trimmable intro/reference redundancy and no bundle files to distribute the detail.

Suggestions

Trim the Clean Code attributes parenthetical ("Consistent, Intentional, Adaptable, Responsible") from the intro — it names a taxonomy that no later step or command depends on.

Consolidate the References section: [Issues introduction] and [Sonar Way QG] resolve to the same URL — use one label and drop the duplicated listing to save tokens.

Add a one-line pointer in Step 5 (e.g., "if RED: fix the new issues or mark pre-existing ones Accepted per Limitations — never lower the gate") to close the feedback loop at the validation step itself.

DimensionReasoningScore

Conciseness

The body is dense and table-driven (scanner matrix, metrics thresholds, anti-patterns) with copy-paste blocks, but two spots could be trimmed: the Clean Code attributes parenthetical ("Consistent, Intentional, Adaptable, Responsible") and the References section that repeats the inline citations. Not a 5 due to these minor instances of over-explanation; not a 3 because there is no padding of concepts Claude already knows.

4 / 5

Actionability

Every step is executable: exact plugin coordinates (sonar-maven-plugin, org.sonarsqube plugin, dotnet-sonarscanner), a complete sonar-project.properties example, full sonar-scanner commands with PR decoration flags, a GitHub Actions YAML snippet, and a threshold table with Sonar Way defaults. Not a 4 because the examples are copy-paste ready and cover the common stacks and both local and CI scan cases.

5 / 5

Workflow Clarity

A clearly sequenced Step 1-5 workflow (install → scope → run → read dashboard → gate) with an explicit validation checkpoint: the quality-gate action "polls the server until the gate result lands and fails the build if it's RED". Error-recovery guidance is present via the anti-patterns table and the brownfield waiver process in Limitations. Not a 4 because both the checkpoint and failure handling are explicit.

5 / 5

Progressive Disclosure

Well-organized sections with clearly signaled, one-level-deep external references, and at ~125 lines nothing needs splitting into bundle files. Not a 5 because the trailing References section duplicates the inline citations, and two labels ([Issues introduction], [Sonar Way QG]) resolve to the same URL — a minor organization redundancy.

4 / 5

Total

18

/

20

Passed

Description

92%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 description: concrete actions, explicit two-scenario 'Use when' triggers, and explicit lens disambiguation from the security skill. Voice is third person and the length is proportionate. The only minor gap is a few missing synonyms such as 'static analysis' or 'code quality'.

DimensionReasoningScore

Specificity

"Run SonarQube/SonarCloud against production code to surface Code Smells, Bugs, and Maintainability ratings" plus "Production-only scope via sonar.exclusions; test code is reviewed separately" lists multiple concrete actions with config-level specifics, comprehensively covering what the skill does. It is not a 4 because there is no meaningful gap in the action coverage for this skill's purpose.

5 / 5

Completeness

Explicitly answers both: what ("Run SonarQube/SonarCloud against production code to surface Code Smells, Bugs, and Maintainability ratings") and when ("Use when a team wants maintainability and technical-debt ratings gating PRs, or when an existing SonarQube project reports numbers nobody has tied to a quality gate") with two concrete trigger scenarios. Not a 4 because the when-clause is explicit and specific rather than merely present.

5 / 5

Trigger Term Quality

Good natural keyword coverage: "SonarQube/SonarCloud", "Code Smells", "Maintainability", "technical-debt ratings gating PRs", "quality gate" — terms users would actually say. It is not a 5 because a few common phrases users might use (e.g., "static analysis", "code quality") are absent.

4 / 5

Distinctiveness Conflict Risk

"the maintainability lens rather than the security lens" explicitly carves out a clear niche against the sibling security-scanning skill, and the SonarQube/SonarCloud domain terms are distinct triggers. Not a 4 because the disambiguation leaves no meaningful overlap risk with closely related skills.

5 / 5

Total

19

/

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

Table of Contents