メニュー
Query SonarCloud API for code quality data. Use when: checking quality gate status, fetching code issues or security hotspots, reviewing metrics (coverage, bugs, code smells), or the user says "sonar", "quality gate", "code quality", "sonarclaude".
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Close the loop after an assign-to-workforce run by turning what actually happened into an accountability artifact — planned versus actual delivery, mid-work decisions, plan drift, evidence-backed delivery claims, and remaining work. The plan the user confirmed is the contract; this skill records where execution obeyed it, where it changed, and what is genuinely safe to claim as delivered. Runs on complete, partial, AND failed runs — failure is reported faithfully, never smoothed over. Use when the user says "summarize delivery", "delivery summary", "wrap up", "close the loop", "what did we actually ship", or "plan versus actual", or after assign-to-workforce merges (or fails to merge) a plan's waves. Authored and maintained in agentculture/devague (origin = devague); guildmaster pulls this skill from here and broadcasts it to the AgentCulture mesh — it is NOT vendored from guildmaster like the inbound skills here.
Ask colleague — a *different* backend/model than you (e.g. a local vLLM Qwen) — to take a scoped repo task off your plate, then fold its answer back. The point isn't a stronger model; it's a second, independent mind, and that diversity is the value: `ask-colleague review` gets a candid second opinion on a diff, `ask-colleague explore` gets a fresh read of an area, `ask-colleague write` hands off a small implementation, `ask-colleague feedback` grades a finished work item (the ROI loop), and `ask-colleague clean` reaps stale/corrupt `colleague/*` branches a crashed run left behind (which can break `git fetch`). Pilot a running work item with `monitor`/`guide`/`stop`. Reach for it REFLEXIVELY, the way you'd lean over to the teammate at the next desk — not only when asked: before you present or open a PR on a non-trivial committed diff, run `review` for a diverse second opinion; for a fresh read of an unfamiliar area whose answer is independent of your current context, run `explore`. Both are read-only — isolate
Search the shared eidetic memory store and get back ranked, provenanced records. Drives `eidetic recall` with four search modes — exact (verbatim substring), approximate (vector/semantic), keyword (BM25 lexical), and hybrid (a weighted blend of vector+keyword, the default) — each hit carrying its text, full metadata, a relevance `score`, and a freshness `signal`. Recall passively reinforces matched records (bumps last_recall + recall_count). Shadowed and archived records are excluded by default; use --include-shadowed / --include-archived to retrieve them. The store uses visibility-aware routing: PUBLIC records inside a git repo go to <repo-root>/.eidetic/memory (committed, team-shared); PRIVATE records, or any record outside a git repo, go to $HOME/.eidetic/memory (never committed). An explicit EIDETIC_DATA_DIR wins and short-circuits to that single dir. Recall reads both stores and merges. The wrapper defaults queries to this agent's PERSONAL, PUBLIC scope (`--scope colleague --visibility public`, suffix re
Ingest records into the shared eidetic memory store so they can be recalled later. Drives `eidetic remember`: accepts one record as a JSON object, or a batch as NDJSON on stdin for bulk ingest. Upsert is idempotent by id (and dedups by content hash) — re-remembering updates in place, never duplicates. Stamps a `created` date on every record at ingest time. Accepts `supersedes` (id of the record this one replaces, for within-scope shadowing via `sweep`) and `links` (list of related-memory ids). The store uses visibility-aware routing: PUBLIC records inside a git repo go to <repo-root>/.eidetic/memory (committed, team-shared); PRIVATE records, or any record outside a git repo, go to $HOME/.eidetic/memory (never committed). An explicit EIDETIC_DATA_DIR wins and short-circuits to that single dir. The wrapper defaults records to this agent's PERSONAL, PUBLIC scope (`--scope colleague --visibility public`, suffix read from culture.yaml) so a plain /remember commits to <repo-root>/.eidetic/memory (in-repo, team-shar
Graduate colleague from a task runner into a persistent Culture mesh peer — the born → trained → resident lifecycle transition. Mints + self-registers a stable mesh identity, selects channels, and (with --serve) connects to IRC and runs the resident until interrupted. Requires the opt-in [culture] extra. Use when an operator wants to elevate their colleague instance into a long-lived Culture member that owns a channel and answers messages directly.
colleague's CI/CD lane, layered on `devex pr` (the same PR-lifecycle CLI as `agex`, invoked under the `devex` name). Delegates lint / open / read / reply / delta to devex; adds two extensions — `status` (SonarCloud quality gate + hotspots + unresolved-thread tally) and `await` (read --wait + status with non-zero exit on Sonar ERROR or unresolved threads). Use when: creating PRs in colleague, handling review feedback, polling CI status, or the user says "create PR", "review comments", "address feedback", "resolve threads". Renamed from `pr-review` in steward 0.7.0; rebased on agex/devex in 0.12.0.
| name | sonarclaude |
| type | command |
| description | Query SonarCloud API for code quality data. Use when: checking quality gate status, fetching code issues or security hotspots, reviewing metrics (coverage, bugs, code smells), or the user says "sonar", "quality gate", "code quality", "sonarclaude". |
Query SonarCloud projects for quality gate status, issues, metrics, and security hotspots.
The script requires the following tools on PATH:
bashcurl — talks to the SonarCloud REST APIjq — parses responses and URL-encodes accept commentsRequires SONAR_TOKEN environment variable. Set the project key per-repo via
the SONAR_PROJECT environment variable (or pass --project KEY on each
invocation).
# Quality gate status (pass/fail)
bash .claude/skills/sonarclaude/scripts/sonar.sh status
# List issues (bugs, vulnerabilities, code smells)
bash .claude/skills/sonarclaude/scripts/sonar.sh issues
# Filter issues by severity and type
bash .claude/skills/sonarclaude/scripts/sonar.sh issues --severity CRITICAL --type BUG
# Key metrics (coverage, bugs, code smells, duplication, LOC)
bash .claude/skills/sonarclaude/scripts/sonar.sh metrics
# Security hotspots
bash .claude/skills/sonarclaude/scripts/sonar.sh hotspots
# Accept (won't-fix) an OPEN issue with a rationale comment
bash .claude/skills/sonarclaude/scripts/sonar.sh accept \
--issue AZ3Ep83i4ywi8V_l99p0 \
--comment "Pushback: rule premise doesn't fit our test fixture pattern."
# Different project
bash .claude/skills/sonarclaude/scripts/sonar.sh status --project OtherOrg_OtherProject
# Raw JSON output
bash .claude/skills/sonarclaude/scripts/sonar.sh issues --raw
# Limit results
bash .claude/skills/sonarclaude/scripts/sonar.sh issues --limit 10
| Flag | Default | Description |
|---|---|---|
--project | $SONAR_PROJECT | SonarCloud project key |
--severity | all | Filter: BLOCKER, CRITICAL, MAJOR, MINOR, INFO |
--type | all | Filter: BUG, VULNERABILITY, CODE_SMELL |
--limit | 25 | Max results returned |
--raw | off | Output raw JSON instead of formatted summary |
--issue | — | Issue key (required for accept) |
--comment | — | Rationale comment (required for accept) |
acceptSonar rules occasionally flag patterns where the rule's premise does not fit the
code (e.g. test fixtures with intentional bad-password literals, contradictory
rule pairs like S7494 vs S7500). After deciding pushback in PR review, run
sonar.sh accept with a rationale comment instead of leaving the issue OPEN —
this moves it to ACCEPTED/WONTFIX in SonarCloud history (visible to future
maintainers) while clearing the quality-gate signal. Always include a --comment
explaining why; silent dismissals are not acceptable curation.
Do not call SonarCloud's HTTP API directly from other skills or one-off
scripts — sonar.sh accept is the supported entry point so the rationale
flow stays consistent.