codyswanngt/lisa-sonarcloud-access
plugins/src/base/skills/lisa-sonarcloud-access/SKILL.md
Vendor-neutral access layer for SonarQube Cloud/Server. Sonar triage skills MUST delegate through this skill rather than calling the SonarQube MCP tools directly. Single substrate: the official SonarQube MCP server (mcp__sonarqube__*), authenticated headlessly from SONARQUBE_CLI_TOKEN (+ SONARQUBE_CLI_ORG for Cloud, SONARQUBE_CLI_SERVER for Server).
$ install --global
skillsauthnpx skillsauth add codyswanngt/lisa lisa-sonarcloud-accessInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
Security Scan Results
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
3
Scanners Passed
9
Scanners in report
Clean
TrivyContainer and dependency vulnerability scanner
95%
Clean
SemgrepStatic code analysis for vulnerabilities
95%
Clean
mcp-scan (Snyk)Model Context Protocol security validation
95%
Skipped
Snyk (dep)Open source security scanning
50%
Skipped
Socket.devSupply chain security analysis
50%
Skipped
VirusTotalMulti-engine malware detection
50%
Skipped
CrowdStrikeAdvanced threat intelligence
50%
Skipped
OSV-ScannerOpen Source Vulnerability database check
50%
Skipped
OWASP Dep-Check
50%
Last scanned: Jul 24, 2026, 3:25 AM39.0s1 file scanned
SKILL.md
- name:
- lisa-sonarcloud-access
- description:
- Vendor-neutral access layer for SonarQube Cloud/Server. Sonar triage skills MUST delegate through this skill rather than calling the SonarQube MCP tools directly. Single substrate: the official SonarQube MCP server (mcp__sonarqube__*), authenticated headlessly from SONARQUBE_CLI_TOKEN (+ SONARQUBE_CLI_ORG for Cloud, SONARQUBE_CLI_SERVER for Server).
- allowed-tools:
- ["Bash", "Read", "Skill"]
SonarCloud Access: $ARGUMENTS
Single chokepoint for Sonar quality and security data. Caller skills MUST NOT
invoke mcp__sonarqube__* tools directly; they ask for data by operation name and
this skill owns the tool selection.
Substrate
There is exactly one substrate: the official SonarQube MCP server, provided by
the sonarqube plugin and launched by the sonar CLI (sonar run mcp). It
authenticates headlessly from environment variables — no browser, no OS keychain —
so it is the same substrate on a developer machine and in a headless cloud routine:
SONARQUBE_CLI_TOKEN— required (Sonar user/analysis token).SONARQUBE_CLI_ORG— required for SonarQube Cloud.SONARQUBE_CLI_SERVER— required for a self-hosted SonarQube Server.
These are the SonarQube CLI variable names (SONARQUBE_CLI_*), which the
sonar run mcp wrapper forwards into the MCP container — verified against a live
SonarQube Cloud org. Do not substitute the raw MCP-image names
(SONARQUBE_TOKEN/SONARQUBE_ORG/SONARQUBE_URL): those are read only when
running the Docker image directly, and the sonar CLI ignores them (auth exits
non-zero). The CI scan gate's SONAR_TOKEN is a third, separate name.
Wiring is performed once by /lisa:setup:sonar (which drives sonar integrate <agent>); this access layer assumes the MCP is already wired. This is distinct
from the CI SONAR_TOKEN secret that authenticates the SonarCloud scan job in
quality.yml — that gate is separate and unchanged.
Probe (tool-access-gate)
Prove access with a cheap read-only MCP call before relying on it — the sonar CLI
being on PATH is not access. Probe by searching projects (the projects toolset is
always enabled):
- If a
mcp__sonarqube__*project-search tool returns, access is proven. - If no
mcp__sonarqube__*tool is present, or the call fails authentication, fail loudly and do not improvise a substitute:
Error: no SonarQube access. Run /lisa:setup:sonar (or `sonar integrate <agent>`), and set SONARQUBE_CLI_TOKEN (+ SONARQUBE_CLI_ORG for Cloud / SONARQUBE_CLI_SERVER for Server).
There is no hand-rolled REST fallback: the official MCP is headless-capable via the token env vars, so it is the only sanctioned substrate. A missing MCP is a tool-access-gate failure to surface, not a reason to curl the Web API.
Operation → toolset map
Consumers pass a coarse, vendor-native operation; resolve it with the matching
mcp__sonarqube__* tool from the named toolset and return parsed JSON in a
<result> block.
| Operation | SonarQube MCP toolset |
|---|---|
| gate-status | quality-gates |
| issues | issues |
| hotspots | security-hotspots |
| rule-detail | rules |
| source-snippet | cag (context augmentation) / component source |
| coverage | coverage |
| duplication | duplications |
| dependency-risks | dependency-risks |
| projects | projects |
Pass the project key through the tool's projectKey argument (or rely on a
server-configured SONARQUBE_PROJECT_KEY); pass branch / pullRequest where the
tool accepts them.
Invariants
- The official SonarQube MCP is the only substrate; there is no REST fallback.
- Auth is env-var only (
SONARQUBE_CLI_TOKEN[+SONARQUBE_CLI_ORG|SONARQUBE_CLI_SERVER]); never the interactivesonar auth loginkeychain flow inside a factory. - Sonar host access requires the host (
sonarcloud.io,sonarqube.us, or the Server URL) in any custom remote-network allowlist. - Consumers ask for data by operation name; this skill owns tool selection.
Related Skills
codyswanngt/lisa-setup-workstation
development
VerifiedTrustedCommunity
Prepare a machine — a fresh laptop or a throwaway container — to run coding agents, before any repository exists. Detects which of Lisa's supported agents (Claude Code, Codex, Cursor, OpenCode, Antigravity, Copilot) are already installed, asks which credential manager the machine uses (Bitwarden, 1Password, Doppler, Vault, AWS, or none), and installs only what is missing, each by its vendor's own preferred method. Idempotent, headless by default, and emits a Dockerfile for a spin-up/spin-down environment. Run it on a new machine, in a container, or before cloning anything.
3SKILL.mdUpdated Aug 30, 2026
codyswanngt/lisa-setup-remote-env
tools
VerifiedTrustedCommunity
Provision and verify a remote execution environment for a host project — Codex Cloud today, other remote surfaces as they are added. Generates a repository-owned setup script that installs the declared toolchain, materializes secrets through lisa-secrets-access, and runs the project's own hook. Provisions by API where one exists, by driving the vendor console where one does not, and by emitting exact config otherwise — then proves the result with the same read-back regardless of which tier did the work. Use before dispatching any work with executionEnv.
3SKILL.mdUpdated Aug 30, 2026
codyswanngt/lisa-setup-local-env
tools
VerifiedTrustedCommunity
Bring a developer's machine in line with the toolchain the project declares. Reports every tool in remoteEnv.tools that is missing, outdated, or unpinned for this platform, and installs the missing ones into ~/.local/bin from the same pinned, checksummed entries the remote surfaces use — but only when asked. Same manifest, same pins, same installers as lisa-setup-remote-env; what differs is consent and that the pin is a floor rather than an equality. Run it on a fresh checkout, after a manifest change, or when a tool fails at the moment of use.
3SKILL.mdUpdated Aug 30, 2026
codyswanngt/lisa-remote-dispatch
tools
VerifiedTrustedCommunity
Route one unit of work to a remote execution surface. Reads the executionEnv parameter (local by default, codex-cloud or claude-web today), verifies the environment is provisioned and bound to this repository, submits a thin skill invocation, records the task identifier to .lisa/remote-dispatch.json, and exits without polling. Routing only — the remote runs the identical skill from the identical repository. Composable and inline: other skills invoke it via the Skill tool rather than users calling it directly.
3SKILL.mdUpdated Aug 30, 2026