Irrlicht: Skill for Claude Code

SonarQube Report (on demand)

SonarQube Cloud's issue search gives concrete, actionable findings — rule key, file, line, message, and estimated fix effort — which is exactly what CodeScene's hotspot API doesn't expose (see the removed ir:codescene-report skill's history for why that mattered). This skill fetches those issues on demand and hands back a short, readable summary.

Unlike CodeScene, there's no GitHub Actions round-trip: SONAR_TOKEN lives in this repo's local .env (gitignored, never a CI secret), so tools/sonarqube-report.sh runs directly.

Prerequisite

.env at the repo root must have SONAR_TOKEN, SONAR_ORGANIZATION, and SONAR_PROJECT_KEY set (see .env.example). If any are missing, the script fails fast with a clear message naming which one — report that directly rather than guessing values.

Also: SonarQube Cloud has no equivalent of CodeScene's run-analysis trigger. Fresh data depends on a scanner (sonar-scanner / a CI action) having already run against this project — this skill only reads whatever the last scan uploaded. If no CI scan is wired up yet, say so rather than treating an empty/stale result as "no issues."

Workflow

1. Fetch

tools/sonarqube-report.sh

This defaults to issues/search scoped to the project, resolved=false (only currently-open issues), sorted by severity descending (worst first), page size 100.

2. Read the result

From each entry in the issues array, pull out:

• component — strip the <SONAR_PROJECT_KEY>: prefix to get the repo-relative file path
• line (or textRange.startLine–textRange.endLine if line is absent — some rule types, e.g. file-level ones, have no single line)
• rule — the rule key (e.g. go:S1192)
• message — usually already actionable on its own (e.g. "Reduce the number of returns of this function from 6 to at most 3")
• effort — estimated remediation time (e.g. "2h1min")
• impacts — array of {softwareQuality, severity} (the current Clean Code taxonomy: MAINTAINABILITY / RELIABILITY / SECURITY × INFO/LOW/MEDIUM/HIGH/BLOCKER); prefer this over the older top-level severity/type fields when summarizing
• flows — if present and non-empty, this is a taint trace (source → sink across possibly multiple files/lines), not just noise. The one-line message alone is often too generic to act on for security-class rules (e.g. gosecurity:S2083's message is always "don't construct the path from user-controlled data" regardless of the actual data path) — for any BLOCKER/CRITICAL issue with a non-empty flows, include the source→sink steps (each location's msg + component/textRange) in the summary. Don't drop this for brevity; it's usually the only part that's actually actionable.