sonarcloud-pr-fix

Sterne2

Forks0

Aktualisiert8. Juni 2026 um 14:00

Use when the user wants to find SonarCloud issues for the current branch pull request, fix them in the local repo, verify with local checks, push the branch, and confirm whether SonarCloud has reanalyzed the PR.

Installation

Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.

Quelle

alkampfergit

alkampfergit/azdo-cli

GitHub-Repository öffnen Creator-Repositorys ansehen

Download

Verwandte BerufeSOC

Basierend auf der SOC-Berufsklassifikation

SoftwareentwicklerInformatik- und Mathematikberufe·SOC 15-1252

SKILL.md

readonly

name	sonarcloud-pr-fix
description	Use when the user wants to find SonarCloud issues for the current branch pull request, fix them in the local repo, verify with local checks, push the branch, and confirm whether SonarCloud has reanalyzed the PR.

SonarCloud PR Fix

Use this skill for PR-scoped SonarCloud cleanup work in this repository.

Goal

Find the SonarCloud issues attached to the current branch's pull request, apply the smallest safe fixes, verify locally, push the branch, and check whether SonarCloud has refreshed on the latest commit.

Default assumptions

Repo root is the current working directory.
The branch usually has an open GitHub pull request.
This repo uses Beads for task tracking.
The usual SonarCloud project key here is alkampfergit_azdo-cli.

Workflow

Recover repo and branch context.
- Read AGENTS.md and CLAUDE.md.
- Run git status --short --branch.
- Run git rev-parse --abbrev-ref HEAD.
- Run bd prime.
Create and claim a Beads issue before editing code.
- Example:
  - bd create --title "Fix SonarCloud pull request issues" --type bug --priority 1 --label "sonarcloud,quality" --description "..."
  - bd update <id> --claim
Resolve the current branch to a GitHub pull request number.
- Preferred:
  - curl -fsSL "https://api.github.com/repos/<owner>/<repo>/pulls?state=open&head=<owner>:<branch>"
- Extract the PR number from the response.
- If there is no open PR, stop and tell the user.
Query SonarCloud for PR issues AND security hotspots (two separate APIs).
- Regular issues (bugs, vulnerabilities, code smells):
  - curl -fsSL "https://sonarcloud.io/api/issues/search?componentKeys=<projectKey>&pullRequest=<prNumber>&ps=100"
- Security hotspots (NOT returned by issues/search — requires a separate call):
  - curl -fsSL "https://sonarcloud.io/api/hotspots/search?projectKey=<projectKey>&pullRequest=<prNumber>&ps=100"
- Also check PR status when needed:
  - curl -fsSL "https://sonarcloud.io/api/project_pull_requests/list?project=<projectKey>"
- Summarize findings by file, rule, and line before editing.
- For hotspots, the fix strategy is to remove or isolate the risky pattern — do NOT mark as "reviewed/safe" unless the code genuinely has no risk:
  - PATH manipulation (S4036) → replace execSync('binary ...') with execFileSync(absoluteResolvedPath, args) where the binary is found at startup by probing well-known absolute paths.
  - Hard-coded credentials → move to environment variables.
  - Unsafe eval / dynamic code → replace with a safe alternative.
Inspect the affected code and nearby tests.
- Read only the files touched by SonarCloud plus relevant tests.
- Prefer targeted fixes over broad refactors.
- Watch for CI-only failures such as tsc --noEmit issues that local npm test may miss.
Apply fixes.
- Use apply_patch for edits.
- Keep behavior stable unless the Sonar issue requires a behavior change.
- Typical fixes:
  - extract helpers to reduce cognitive complexity
  - simplify negated conditions
  - replace String#replace() with replaceAll() when global replacement is intended
  - prefer RegExp.exec() when Sonar requests it
Verify locally.
- Minimum when TypeScript code changes:
  - npm run typecheck
  - npm test
  - npm run lint
- If a command fails, fix that before pushing.
Commit and push.
- Use non-interactive git commands only.
- Run:
  - git add <files>
  - git commit -m "<message>"
  - git pull --rebase
  - bd dolt push
  - git push
- If bd dolt push fails because no Dolt remote is configured, do not invent one.
  - Report the exact failure.
  - Create a follow-up Beads issue for the missing Dolt remote if one does not already exist.
  - Still complete git push.
Recheck remote status.
- Confirm branch state:
  - git status --short --branch
- Check GitHub checks for the pushed commit:
  - curl -fsSL "https://api.github.com/repos/<owner>/<repo>/commits/<sha>/check-runs" -H "Accept: application/vnd.github+json"
- Requery SonarCloud:
  - curl -fsSL "https://sonarcloud.io/api/project_pull_requests/list?project=<projectKey>"
  - curl -fsSL "https://sonarcloud.io/api/issues/search?componentKeys=<projectKey>&pullRequest=<prNumber>&ps=100"
Report final state precisely.

Include:
- PR number
- files changed
- local verification results
- pushed commit SHA
- whether SonarCloud has reanalyzed the latest commit yet
- any remaining blocker outside the code changes

Notes

SonarCloud can lag behind GitHub pushes. If SonarCloud still shows an older analysisDate or commit SHA, say so explicitly instead of claiming the issues remain.
GitHub Actions may reveal stricter typecheck failures than npm test if typecheck is not part of the test script. Always run npm run typecheck for TypeScript changes.
Do not close the loop with "ready to push". Push the branch unless the user explicitly tells you not to.

Mehr aus diesem Repository

gleiches Repository

bugfix

alkampfergit/azdo-cli

Fix a GitHub bug issue end-to-end — analyze the codebase, write failing tests, commit them to a bugfix/<id> branch, implement the fix, and open a PR with a full investigation log. After the PR opens, poll it for owner feedback at configurable intervals until stood down. Trigger on a single issue (/bugfix

2026-06-262

maintainer

alkampfergit/azdo-cli

Routine repository security-maintenance pass. Create a fresh branch, use the gh CLI to enumerate security problems (Dependabot, code scanning, secret scanning), fix the actionable ones, verify, open a pull request, then hand off to /github-pr-fixer. Use when the user says "run maintainer", "do a security maintenance pass", "fix the security problems and open a PR", or similar.

2026-06-202

speckit-gh

alkampfergit/azdo-cli

Drive a single GitHub issue through the full speckit pipeline (specify → clarify → plan → tasks → PR-report → draft PR → implement → test → ready → CI → review) using the `gh` CLI. Fully human-in-the-loop — every speckit phase posts its artefact on the issue and polls for owner approval. All user communication stays on the issue / PR threads, never the console. Use when the user says "implement issue

2026-06-112

sonarcloud

alkampfergit/azdo-cli

Analyze and fix SonarCloud issues on pull requests. Use when the user mentions SonarCloud, quality gate, code smells, duplication, or wants to check PR quality status. Reads issues via GitHub API, creates fix plans, and applies fixes with awareness of parallel agent safety.

2026-06-052

changelog

alkampfergit/azdo-cli

Keep a slim, human-readable CHANGELOG. The root CHANGELOG.md holds only a short stanza per release (theme + a few brief bullets + a link); full per-release detail lives in docs/changelogs/<version>.md, with docs/changelogs/unreleased.md accumulating the next release. Versions follow the tags on master — if master is at 0.11.x, unreleased work on develop belongs to 0.12.0. Use when the user says "record a changelog entry", "update the changelog", "finalise the changelog for a release", or "split the changelog".

2026-06-012

gitflow

alkampfergit/azdo-cli

Drive a gitflow release end-to-end — resolve the current version from the latest tag on master, compute the next version (minor bump by default, or caller-specified), run `git flow release start/finish`, and push `master`, `develop`, and the new tag. Use when the user says "release X.Y.Z", "cut a release", or when speckit-full picks up a release issue.

2026-04-242

SonarCloud PR Fix

Use this skill for PR-scoped SonarCloud cleanup work in this repository.

Goal

Default assumptions

Repo root is the current working directory.

The branch usually has an open GitHub pull request.

This repo uses Beads for task tracking.

The usual SonarCloud project key here is alkampfergit_azdo-cli.

Workflow

Recover repo and branch context.

Read AGENTS.md and CLAUDE.md.
Run git status --short --branch.
Run git rev-parse --abbrev-ref HEAD.
Run bd prime.

Create and claim a Beads issue before editing code.

Example:
- bd create --title "Fix SonarCloud pull request issues" --type bug --priority 1 --label "sonarcloud,quality" --description "..."
- bd update <id> --claim

Resolve the current branch to a GitHub pull request number.

Preferred:
- curl -fsSL "https://api.github.com/repos/<owner>/<repo>/pulls?state=open&head=<owner>:<branch>"
Extract the PR number from the response.
If there is no open PR, stop and tell the user.

Query SonarCloud for PR issues AND security hotspots (two separate APIs).

Regular issues (bugs, vulnerabilities, code smells):
- curl -fsSL "https://sonarcloud.io/api/issues/search?componentKeys=<projectKey>&pullRequest=<prNumber>&ps=100"
Security hotspots (NOT returned by issues/search — requires a separate call):
- curl -fsSL "https://sonarcloud.io/api/hotspots/search?projectKey=<projectKey>&pullRequest=<prNumber>&ps=100"
Also check PR status when needed:
- curl -fsSL "https://sonarcloud.io/api/project_pull_requests/list?project=<projectKey>"
Summarize findings by file, rule, and line before editing.
For hotspots, the fix strategy is to remove or isolate the risky pattern — do NOT mark as "reviewed/safe" unless the code genuinely has no risk:
- PATH manipulation (S4036) → replace execSync('binary ...') with execFileSync(absoluteResolvedPath, args) where the binary is found at startup by probing well-known absolute paths.
- Hard-coded credentials → move to environment variables.
- Unsafe eval / dynamic code → replace with a safe alternative.

Inspect the affected code and nearby tests.

Read only the files touched by SonarCloud plus relevant tests.
Prefer targeted fixes over broad refactors.
Watch for CI-only failures such as tsc --noEmit issues that local npm test may miss.

Apply fixes.

Use apply_patch for edits.
Keep behavior stable unless the Sonar issue requires a behavior change.
Typical fixes:
- extract helpers to reduce cognitive complexity
- simplify negated conditions
- replace String#replace() with replaceAll() when global replacement is intended
- prefer RegExp.exec() when Sonar requests it

Verify locally.

Minimum when TypeScript code changes:
- npm run typecheck
- npm test
- npm run lint
If a command fails, fix that before pushing.

Commit and push.

Use non-interactive git commands only.
Run:
- git add <files>
- git commit -m "<message>"
- git pull --rebase
- bd dolt push
- git push
If bd dolt push fails because no Dolt remote is configured, do not invent one.
- Report the exact failure.
- Create a follow-up Beads issue for the missing Dolt remote if one does not already exist.
- Still complete git push.

Recheck remote status.

Confirm branch state:
- git status --short --branch
Check GitHub checks for the pushed commit:
- curl -fsSL "https://api.github.com/repos/<owner>/<repo>/commits/<sha>/check-runs" -H "Accept: application/vnd.github+json"
Requery SonarCloud:
- curl -fsSL "https://sonarcloud.io/api/project_pull_requests/list?project=<projectKey>"
- curl -fsSL "https://sonarcloud.io/api/issues/search?componentKeys=<projectKey>&pullRequest=<prNumber>&ps=100"

Report final state precisely.

Include:

PR number
files changed
local verification results
pushed commit SHA
whether SonarCloud has reanalyzed the latest commit yet
any remaining blocker outside the code changes

Notes

SonarCloud can lag behind GitHub pushes. If SonarCloud still shows an older analysisDate or commit SHA, say so explicitly instead of claiming the issues remain.

GitHub Actions may reveal stricter typecheck failures than npm test if typecheck is not part of the test script. Always run npm run typecheck for TypeScript changes.

Do not close the loop with "ready to push". Push the branch unless the user explicitly tells you not to.