SonarQube New Code Warning Fixer

Overview

Use SonarQube MCP to inspect only newly updated code, report warnings in a clear list, fix them, and finish with passing tests. Scope selection supports uncommitted changes and branch diffs.

Workflow

1. Determine update scope. Run:

python3 scripts/list_newly_updated_files.py --mode auto --only code

• auto: use uncommitted changes when present; otherwise use branch diff.
• branch diff base: prefer develop, then master, then main.
• if no changed code files are found, report no warnings and stop.

2. Resolve SonarQube project key.

• infer from repo name first.
• call mcp__sonarqube__search_my_sonarqube_projects.
• if multiple close matches exist, choose exact key match when available.

3. Convert changed files to Sonar component keys. Run:

python3 scripts/list_newly_updated_files.py --mode auto --only code --project-key "<project-key>"

• use sonar_components.prod and sonar_components.test.
• query production and test components separately to avoid Sonar qualifier errors.

4. Collect warnings on changed files with SonarQube MCP.

• primary issues: mcp__sonarqube__search_sonar_issues_in_projects
  • set projects=[projectKey]
  • set issueStatuses=["OPEN","CONFIRMED"]
  • batch components to keep requests small (around 25 to 50 files per call).
• security warnings: mcp__sonarqube__search_security_hotspots
  • set projectKey
  • pass the same file batch (path list, not component keys).
  • include unresolved statuses only.

5. Show warning list before fixing.

• sort by severity: BLOCKER, CRITICAL, MAJOR, MINOR, INFO.
• include: issue key, severity, rule, file, line, message.
• explicitly state Warnings found: 0 when empty.

6. Fix all warnings in changed files.

• fix highest severity first.
• preserve behavior unless warning explicitly points to a bug.
• avoid widening scope beyond changed files except for necessary shared utilities.
• after edits, re-query Sonar for the same changed-file scope.

7. Fix broken tests and validate.

• run focused tests for touched modules first, then broader suite if needed.
• if the repo has no reliable targeted mapping, run project default test command.
• report remaining failures with exact test name and error.
• continue until warnings on changed files are resolved and tests pass, or clearly report blockers.

Output Format

Use this order:

1. Scope summary.
2. Warning list.
3. Fixes applied.
4. Test results.
5. Residual blockers (if any).

Resources

• changed-file scope helper: scripts/list_newly_updated_files.py
• Sonar query patterns and caveats: references/sonarqube-mcp-patterns.md

Sharing

Install this skill from a skills repository:

npx skills add <repo-url-or-path> --skill sonarqube-new-code-warning-fixer

Guardrails

• keep analysis scoped to newly updated code unless user asks for full-project scan.
• never hide unresolved warnings: list them explicitly.
• do not claim tests passed unless tests were actually run in this environment.
• if Sonar returns no results but warnings are expected, verify project key, file key format, and qualifier grouping before concluding.