← SonarQubeCONTENT HISTORY

Update to SonarQube

Snapshot Sep 30, 2026 · 23:13 UTC · version 2.6.0

Collection source: not recorded for this historical snapshot.

WHAT CHANGED · RULE-BASED ANALYSIS

First saved snapshot

No earlier snapshot is available to establish a change.

Compare saved observations

Download comparison JSON
Full technical diff · 0 changed fields
Full snapshot data
{
  "description": "Find files with low test coverage and inspect uncovered lines in a SonarQube project (project key optional when MCP integration already defines the default project)",
  "included_files": [],
  "name": "sonar-coverage",
  "skill_md_contents": "---\nname: sonar-coverage\ndescription: Find files with low test coverage and inspect uncovered lines in a SonarQube project (project key optional when MCP integration already defines the default project)\nargument-hint: \"[project-key?] [--max n] [--file key] [--pr id]\"\nallowed-tools: Read, Grep, Bash(docker ps:*), Bash(podman ps:*), Bash(nerdctl ps:*), Bash(sonar:*)\n---\n\n# SonarQube — Coverage\n\nIdentify files with insufficient test coverage and pinpoint the exact lines that need tests.\n\n## Usage\n\n```\nsonar-coverage                              # worst-covered files in the current project\nsonar-coverage my-project                   # worst-covered files in a specific project\nsonar-coverage my-project --max 50          # only files with coverage <= 50%\nsonar-coverage my-project --file src/auth/login.py  # line-by-line detail for one file\n```\n\n## Prerequisites\n\nThis skill requires the SonarQube MCP Server to be configured and the tools `mcp__sonarqube__search_files_by_coverage` and `mcp__sonarqube__get_file_coverage_details` to be available in your session.\n\n**Before proceeding**, verify the tools are accessible. If they are not, try the `sonar api` CLI fallback in Step 3 before giving up — don't invent other CLI commands (e.g. `sonar mcp call` or `sonar coverage` do not exist).\n\n**If the CLI fallback also fails (for example `sonar` not installed/authenticated, or no project key can be resolved), narrow down the cause** — check whether the `sonarqube` MCP server is enabled in this agent's configuration.\n\n- **Not enabled / not registered** → recommend running the sonar-integrate skill.\n- **Enabled but its tools are still unavailable** → configuration is correct but the server failed to start. The most common cause is that the container runtime is not running — the MCP server launches inside Docker/Podman/Nerdctl via `sonar run mcp`, so a correctly configured server still produces no tools if the daemon is stopped. Run `docker ps` yourself (falling back to `podman ps` / `nerdctl ps`) to confirm which cause applies: if it errors, the runtime is down; after the user starts it, confirm the same command succeeds before asking them to restart the agent session.\n\nEither way, show the user:\n\n> Unable to reach the SonarQube MCP Server, or project key not found.\n>\n> **Possible causes:**\n> - MCP server not registered — invoke the sonar-integrate skill to configure the SonarQube MCP Server, then restart the agent session\n> - Container runtime not running — the SonarQube MCP Server runs inside a container (Docker, Podman, or Nerdctl); start your container runtime, then restart the agent session\n> - Credentials not configured — invoke the sonar-integrate skill\n> - Project key is wrong or no default project in MCP config — pass an explicit key, or verify `sonar-project.properties` / re-run the sonar-integrate skill for this project\n\nThen ask the user (yes/no) whether to run the sonar-integrate skill now. Briefly explain what it does: it checks the SonarQube setup on their machine — installing or updating `sonarqube-cli` and verifying authentication — and re-configures the integration for this agent, including the SonarQube MCP server and secrets-scanning hooks. If they confirm, invoke the sonar-integrate skill yourself and follow it end-to-end in this session, then ask the user to ensure a container runtime (Docker, Podman, or Nerdctl) is running and to restart the agent session so the new MCP tools become available; if they decline, stop.\n\n## Instructions\n\n### Step 1: Resolve the project key (only when needed)\n\nMCP tools sometimes **do not require** `projectKey` after the sonar-integrate skill has stored the default project for this workspace. Resolve a key only when you must pass it (tool schema requires it, or the user targets another project):\n\n- If the user provided a project key, use it.\n- Otherwise look for `sonar.projectKey` in `sonar-project.properties` at the repo root.\n- If still not found, **omit `projectKey`** in MCP calls and rely on the integration default.\n\n### Step 2: Parse optional flags from the user-provided arguments\n\n| Flag           | Meaning                                                                     |\n| -------------- | --------------------------------------------------------------------------- |\n| `--max <n>`    | Only return files with coverage ≤ n% (maps to `maxCoverage`)                |\n| `--pr <id>`    | Analyse a pull request instead of the main branch                           |\n| `--file <key>` | Skip the file list and go straight to line-by-line detail for this file key |\n\n### Step 3: Run the appropriate flow\n\n#### Flow A — File list (default, no `--file`)\n\nCall `mcp__sonarqube__search_files_by_coverage`. Include **`projectKey` only if** you resolved one in Step 1 **and** the tool requires it; otherwise omit it.\n\n```json\n{\n  \"projectKey\": \"<only-if-required>\",\n  \"maxCoverage\": <n>,       // if --max was given\n  \"pullRequest\": \"<id>\",    // if --pr was given\n  \"pageSize\": 20\n}\n```\n\nOmit `projectKey` from the payload entirely when the default project from integration applies. Omit unused optional fields.\n\nPresent results as a table sorted by coverage ascending:\n\n```markdown\n## Coverage — `my-project`\n\nFiles with lowest coverage (worst first):\n\n| File                | Coverage |\n| ------------------- | -------- |\n| src/auth/login.py   | 12.5%    |\n| src/utils/crypto.py | 23.0%    |\n| src/api/routes.py   | 41.8%    |\n```\n\nIf no files are returned (all files exceed the threshold), say: *\"All files meet the coverage threshold.\"*\n\nThen offer to drill in:\n*\"Ask me to inspect any of these files for uncovered lines, or invoke the sonar-coverage skill with `--file <file-key>` (add a project key only if needed).\"*\n\n**If `mcp__sonarqube__search_files_by_coverage` is unavailable, fall back to `sonar api`.** This needs an explicit project key (no MCP default) — if none was resolved in Step 1, ask the user or invoke sonar-list-projects, then stop.\n\n```bash\nsonar api get \"/api/measures/component_tree?component=<project-key>&metricKeys=coverage,line_coverage,branch_coverage&qualifiers=FIL&strategy=leaves&s=metric&metricSort=coverage&asc=true[&pullRequest=<id>]\"\n```\n\nUse `metricKeys`. If a call 400s unexpectedly, add `-v` to see the actual server error. Read `coverage` from each component's `measures` array and present it in the same table format above.\n\n#### Flow B — Line detail (`--file <key>` given, or user asks to inspect a file)\n\nCall `mcp__sonarqube__get_file_coverage_details`:\n\n```json\n{\n  \"key\": \"<file-key>\",\n  \"pullRequest\": \"<id>\"   // if --pr was given\n}\n```\n\nThe file key format is `<projectKey>:<path>`, e.g. `my-project:src/auth/login.py`.\nIf the user provides just a path, prepend the resolved project key when you have one; if the integration supplies the default project, the detail tool may accept the path or key format your MCP schema documents — follow the tool schema.\n\nPresent uncovered and partially covered lines:\n\n```markdown\n## Coverage Detail — `src/auth/login.py`\n\nOverall coverage: **12.5%**\n\n### Uncovered lines\nLines with no test coverage: 14, 15, 23, 45–52, 67\n\n### Partially covered branches\n| Line | Covered branches | Total branches |\n| ---- | ---------------- | -------------- |\n| 30   | 1                | 2              |\n| 61   | 0                | 2              |\n```\n\nIf the file is fully covered, say: *\"All lines in this file are covered.\"*\n\n**If `mcp__sonarqube__get_file_coverage_details` is unavailable, fall back to `sonar api`:**\n\n```bash\nsonar api get \"/api/sources/lines?key=<file-key>[&pullRequest=<id>]\"\n```\n\nEach returned line has coverage fields (covered/uncovered, branch hit counts) — derive the uncovered-lines list and partially-covered-branches table from those.\n\nIf this also fails, show the standard message above — don't guess further commands.\n\n### Step 4: Next steps\n\n- To write tests for uncovered lines: *\"Ask me to add tests for the uncovered lines above.\"*\n- To check for quality issues in the same file: *\"Invoke the sonar-list-issues skill with `--component <file>`.\"*\n- To check the quality gate: *\"Invoke the sonar-quality-gate skill (add a project key only if you are not using the integration default).\"*\n"
}

SHA-256 of public snapshot: d4d6127bf55a8e5dde665271d103d9dbd6b07574bb7fbb56bc10332920694f79