Update to SonarQube

SKILL.md text changes

− removed · + added

--- before
+++ after
@@ -1,135 +1,133 @@
----
-name: sonar-dependency-risks
-description: Search for software composition analysis (SCA) dependency risks in a SonarQube project (project key optional when MCP integration already defines the default project)
-argument-hint: "[project-key?] [--branch name] [--pr id]"
-allowed-tools: Read, Grep, Bash(docker ps:*), Bash(podman ps:*), Bash(nerdctl ps:*), Bash(sonar:*)
----
-
-# SonarQube — Dependency Risks
-
-Search for dependency risks (software composition analysis issues) in a SonarQube project, paired with the releases that appear in the analysed project, application, or portfolio.
-
-## Usage
-
-```
-sonar-dependency-risks                    # risks in the current project
-sonar-dependency-risks my-project         # risks in a specific project
-sonar-dependency-risks my-project --branch feature/auth
-sonar-dependency-risks my-project --pr 42
-```
-
-## Prerequisites
-
-This skill requires SonarQube Advanced Security (available on SonarQube Cloud Enterprise plan, or SonarQube Server 2025.4 Enterprise edition or higher), the SonarQube MCP Server to be configured, and the tool `mcp__sonarqube__search_dependency_risks` to be available in your session.
-
-**Before proceeding**, verify the tool is accessible. If it is not, try the CLI fallback in Step 3 before giving up — don't invent other CLI commands (e.g. `sonar mcp call` or `sonar dependency-risks` do not exist).
-
-**If the CLI fallback also fails or doesn't apply, narrow down the cause** — check whether the `sonarqube` MCP server is enabled in this agent's configuration. (This only explains missing tools, not the Advanced Security entitlement — see the first cause below.)
-
-- **Not enabled / not registered** → recommend running the sonar-integrate skill.
-- **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.
-
-Either way, show the user:
-
-> Unable to fetch dependency risks.
->
-> **Possible causes:**
-> - This feature requires SonarQube Advanced Security — available on SonarQube Cloud Enterprise edition, or SonarQube Server 2025.4 Enterprise or higher
-> - MCP server not registered — invoke the sonar-integrate skill to configure the SonarQube MCP Server, then restart the agent session
-> - 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
-> - Credentials not configured — invoke the sonar-integrate skill
-> - 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
-
-Then 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.
-
-## Instructions
-
-### Step 1: Resolve the project key (only when needed)
-
-MCP 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):
-
-- If the user provided a project key, use it.
-- Otherwise look for `sonar.projectKey` in `sonar-project.properties` at the repo root.
-- If still not found, **omit `projectKey`** in MCP calls and rely on the integration default.
-
-### Step 2: Parse optional flags from the user-provided arguments
-
-| Flag              | Maps to parameter |
-| ----------------- | ----------------- |
-| `--branch <name>` | `branchKey`       |
-| `--pr <id>`       | `pullRequestKey`  |
-
-### Step 3: Call `mcp__sonarqube__search_dependency_risks`
-
-Include **`projectKey` only if** you resolved one in Step 1 **and** the tool requires it; otherwise omit it.
-
-```json
-{
-  "projectKey": "<only-if-required>",
-  "branchKey": "<name>",       // if --branch was given
-  "pullRequestKey": "<id>"     // if --pr was given
-}
-```
-
-Omit `projectKey` from the payload when the integration default applies. Omit unused optional fields.
-
-**If `mcp__sonarqube__search_dependency_risks` is unavailable, fall back to the CLI.** This needs an explicit project key — if none was resolved in Step 1, ask the user or invoke sonar-list-projects, then stop.
-
-Run `sonar auth status` to check the connected server. On a self-hosted **SonarQube Server**:
-
-```bash
-sonar api get "/api/v2/sca/issues-releases?projectKey=<project-key>[&branchKey=<name>][&pullRequestKey=<id>]"
-```
-
-On **SonarQube Cloud**, `sonar api` can't reach this endpoint yet (lives on a separate subdomain; may change in a future CLI release) — run a fresh scan instead:
-
-```bash
-sonar analyze dependency-risks -p <project-key> --format table
-```
-
-This re-scans manifests rather than querying prior results, so it may surface issues not yet on the server dashboard — expected, not an error. Map its output into the same table as Step 4.
-
-If this also fails, show the standard message above — don't guess further commands.
-
-### Step 4: Format the results
-
-**If risks are found**, group by severity and present as a table:
-
-```markdown
-## Dependency Risks — `my-project` (branch: `main`)
-
-Found **5 dependency risk(s)**:
-
-### Critical
-| Dependency | Version | Risk                  | CVE            |
-| ---------- | ------- | --------------------- | -------------- |
-| log4j-core | 2.14.1  | Remote code execution | CVE-2021-44228 |
-
-### High
-| Dependency       | Version | Risk                          | CVE            |
-| ---------------- | ------- | ----------------------------- | -------------- |
-| jackson-databind | 2.12.3  | Deserialization vulnerability | CVE-2021-46877 |
-| commons-text     | 1.9     | Remote code execution         | CVE-2022-42889 |
-
-### Medium
-| Dependency    | Version | Risk              | CVE            |
-| ------------- | ------- | ----------------- | -------------- |
-| spring-web    | 5.3.18  | DoS vulnerability | CVE-2022-22965 |
-| netty-handler | 4.1.68  | SSL/TLS issue     | CVE-2021-43797 |
-```
-
-Omit columns that are not present in the response. Omit severity sections that have no risks.
-
-**If no risks are found**:
-
-```markdown
-## Dependency Risks — `my-project`
-
-✅ No dependency risks found.
-```
-
-### Step 5: Next steps
-
-- To fix a vulnerable dependency: *"Ask me to update `<dependency>` to a safe version."*
-- To check the quality gate: *"Invoke the sonar-quality-gate skill (add a project key only if you are not using the integration default)."*
-- To check code-level security issues: *"Invoke the sonar-list-issues skill with the project key (or use `sonar.projectKey` in the repo) with filters as needed — `sonar list issues` always requires `-p`."*
+---
+name: sonar-dependency-risks
+description: Search for software composition analysis (SCA) dependency risks in a SonarQube project (project key optional when MCP integration already defines the default project)
+argument-hint: "[project-key?] [--branch name] [--pr id]"
+allowed-tools: Read, Grep, Bash(docker ps:*), Bash(podman ps:*), Bash(nerdctl ps:*), Bash(sonar:*)
+---
+
+# SonarQube — Dependency Risks
+
+Search for dependency risks (software composition analysis issues) in a SonarQube project, paired with the releases that appear in the analysed project, application, or portfolio.
+
+## Usage
+
+```
+sonar-dependency-risks                    # risks in the current project
+sonar-dependency-risks my-project         # risks in a specific project
+sonar-dependency-risks my-project --branch feature/auth
+sonar-dependency-risks my-project --pr 42
+```
+
+## Prerequisites
+
+This skill requires SonarQube Advanced Security (available on SonarQube Cloud Enterprise plan, or SonarQube Server 2025.4 Enterprise edition or higher), the SonarQube MCP Server to be configured, and the tool `mcp__sonarqube__search_dependency_risks` to be available in your session.
+
+**Before proceeding**, verify the tool is accessible. If it is not, try the CLI fallback in Step 3 before giving up — don't invent other CLI commands (e.g. `sonar mcp call` or `sonar dependency-risks` do not exist).
+
+**If the CLI fallback also fails or doesn't apply, narrow down the cause** — check whether the `sonarqube` MCP server is enabled in this agent's configuration. (This only explains missing tools, not the Advanced Security entitlement — see the first cause below.)
+
+- **Not enabled / not registered** → recommend running the sonar-integrate skill.
+- **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.
+
+Either way, show the user:
+
+> Unable to fetch dependency risks.
+>
+> **Possible causes:**
+> - This feature requires SonarQube Advanced Security — available on SonarQube Cloud Enterprise edition, or SonarQube Server 2025.4 Enterprise or higher
+> - MCP server not registered — invoke the sonar-integrate skill to configure the SonarQube MCP Server, then restart the agent session
+> - 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
+> - Credentials not configured — invoke the sonar-integrate skill
+> - 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
+
+Then 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.
+
+## Instructions
+
+### Step 1: Resolve the project key (only when needed)
+
+MCP 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):
+
+- If the user provided a project key, use it.
+- Otherwise look for `sonar.projectKey` in `sonar-project.properties` at the repo root.
+- If still not found, **omit `projectKey`** in MCP calls and rely on the integration default.
+
+### Step 2: Parse optional flags from the user-provided arguments
+
+| Flag              | Maps to parameter |
+| ----------------- | ----------------- |
+| `--branch <name>` | `branchKey`       |
+| `--pr <id>`       | `pullRequestKey`  |
+
+### Step 3: Call `mcp__sonarqube__search_dependency_risks`
+
+Include **`projectKey` only if** you resolved one in Step 1 **and** the tool requires it; otherwise omit it.
+
+```json
+{
+  "projectKey": "<only-if-required>",
+  "branchKey": "<name>",       // if --branch was given
+  "pullRequestKey": "<id>",    // if --pr was given
+  "pageIndex": 1,
+  "pageSize": 50
+}
+```
+
+Omit `projectKey` from the payload when the integration default applies. Omit unused optional fields.
+
+If a page returns 50 results, request the next page with `pageIndex` incremented. Stop when a page contains fewer than 50 results, and combine all pages in the order they were returned.
+
+**If `mcp__sonarqube__search_dependency_risks` is unavailable, fall back to the CLI.** This needs an explicit project key — if none was resolved in Step 1, ask the user or invoke sonar-list-projects, then stop.
+
+The same command works on SonarQube Server and SonarQube Cloud — `sonar api` routes the V2 path to the right host:
+
+```bash
+sonar api get "/api/v2/sca/issues-releases?projectKey=<project-key>[&branchKey=<name>][&pullRequestKey=<id>]&pageIndex=1&pageSize=50"
+```
+
+Paginate the same way as the MCP call, using `page.total` from the response to know when you have every result. Each entry in `issuesReleases` carries the risk `key`, `status`, `severity`, `vulnerabilityId`, and the package under `release`.
+
+If this also fails, show the standard message above — don't guess further commands.
+
+### Step 4: Format the results
+
+**If risks are found**, group by severity and present as a table:
+
+```markdown
+## Dependency Risks — `my-project` (branch: `main`)
+
+Found **5 dependency risk(s)**:
+
+### Critical
+| Dependency | Version | Risk                  | CVE            |
+| ---------- | ------- | --------------------- | -------------- |
+| log4j-core | 2.14.1  | Remote code execution | CVE-2021-44228 |
+
+### High
+| Dependency       | Version | Risk                          | CVE            |
+| ---------------- | ------- | ----------------------------- | -------------- |
+| jackson-databind | 2.12.3  | Deserialization vulnerability | CVE-2021-46877 |
+| commons-text     | 1.9     | Remote code execution         | CVE-2022-42889 |
+
+### Medium
+| Dependency    | Version | Risk              | CVE            |
+| ------------- | ------- | ----------------- | -------------- |
+| spring-web    | 5.3.18  | DoS vulnerability | CVE-2022-22965 |
+| netty-handler | 4.1.68  | SSL/TLS issue     | CVE-2021-43797 |
+```
+
+Omit columns that are not present in the response. Omit severity sections that have no risks.
+
+**If no risks are found**:
+
+```markdown
+## Dependency Risks — `my-project`
+
+✅ No dependency risks found.
+```
+
+### Step 5: Next steps
+
+- To fix a vulnerable dependency: *"Ask me to update `<dependency>` to a safe version."*
+- To check the quality gate: *"Invoke the sonar-quality-gate skill (add a project key only if you are not using the integration default)."*
+- To check code-level security issues: *"Invoke the sonar-list-issues skill with the project key (or use `sonar.projectKey` in the repo) with filters as needed — `sonar list issues` always requires `-p`."*