skilldrop-cli 0.16.3__py3-none-any.whl

skilldrop_cli/data/packs/dev-team/skills/pre-merge-review/manifest.json

@@ -0,0 +1,15 @@
+{
+  "name": "pre-merge-review",
+  "version": "0.1.2",
+  "description": "Gate an existing change for merge — run one skill that fires the whole production-readiness pass. First a deterministic mechanical gate (lint + typecheck + tests, via a script whose exit code decides), then the three-reviewer panel dispatched in parallel — devils-advocate (correctness), security-reviewer (exploitability), code-quality (craft) — then a single READY / NOT READY verdict. Use before opening a PR or merging, when you want the full review fleet run on a diff you already have. Do NOT use to implement a feature from a spec (that's feature-implement-loop) or to review a document (that's doc-critique).",
+  "entrypoint": "SKILL.md",
+  "deps": { "npm": [], "pip": [] },
+  "env": { "required": [], "optional": [] },
+  "related": ["feature-implement-loop", "devils-advocate", "council-review", "doc-critique"],
+  "handoff": [
+    { "to": "council-review", "when": "the blocker is a design disagreement, not a defect", "purpose": "Adjudicate the disagreement outside the diff.", "fallback": "If council-review is absent, state each position and its strongest counter inline, and name the crux the decision turns on." }
+  ],
+  "tags": ["dev-workflow", "code-review", "pre-merge", "quality-gate", "subagents", "production-readiness"],
+  "permissions": {"network": [], "commands": ["git", "ruff", "mypy", "pytest", "*"], "files": "project", "notes": "Runs the lint, typecheck and test commands configured for the project, through a shell, by design. --install-hook writes a git pre-commit hook in the repository."},
+  "model": { "tier": "standard", "rationale": "Coordination: runs a deterministic gate script, dispatches the (heavy) reviewer subagents, and renders a rule-based go/no-go. The adversarial reasoning is delegated to the panel, so the skill itself is orchestration, not deep judgment." }
+}

skilldrop_cli/data/packs/dev-team/skills/pre-merge-review/scripts/gate.py

@@ -0,0 +1,189 @@
+#!/usr/bin/env python3
+"""Mechanical merge gate — run a project's verify commands and exit non-zero if any fail.
+
+The deterministic half of `pre-merge-review`: the pass/fail verdict comes from *running real
+commands*, not from a judgment call, so an agent can't talk its way past a red gate. The commands
+are the operator's own (auto-detected, or supplied) — this is a local dev tool, not a sandbox.
+
+  python3 gate.py                      # auto-detect lint / typecheck / test for the project
+  python3 gate.py --cmd "npm test" --cmd "npm run lint"   # explicit commands (repeatable)
+  python3 gate.py --config gate.json   # {"commands": ["pytest -q", "ruff check ."]}
+  python3 gate.py --list               # print what it would run, don't run
+  python3 gate.py --root path/to/repo  # run against another project root
+
+Precedence: --cmd (explicit) > --config > auto-detect. Runs each command in order, streams its
+output, prints a PASS/FAIL line per command and an overall verdict. Exit 0 iff every command
+passed; 1 if any failed; 2 if there was nothing to run. Stdlib only; no network.
+"""
+import argparse
+import json
+import os
+import re
+import shlex
+import shutil
+import subprocess
+import sys
+
+HOOK_MARKER = "skilldrop-gate"
+
+
+def detect(root):
+    """Best-effort verify commands for common stacks. Modest on purpose — an operator with a
+    non-standard setup passes --cmd/--config; auto-detect covers the usual cases."""
+    cmds = []
+    has = lambda f: os.path.exists(os.path.join(root, f))
+
+    if any(has(f) for f in ("pyproject.toml", "setup.py", "pytest.ini", "tox.ini")):
+        if shutil.which("ruff"):
+            cmds.append("ruff check .")
+        if shutil.which("mypy") and has("mypy.ini") or (shutil.which("mypy") and has("pyproject.toml")):
+            cmds.append("mypy .")
+        if shutil.which("pytest"):
+            cmds.append("pytest -q")
+
+    if has("package.json"):
+        try:
+            scripts = json.load(open(os.path.join(root, "package.json"))).get("scripts", {})
+        except (OSError, json.JSONDecodeError):
+            scripts = {}
+        if "lint" in scripts:
+            cmds.append("npm run lint")
+        if "typecheck" in scripts:
+            cmds.append("npm run typecheck")
+        if "test" in scripts:
+            cmds.append("npm test")
+
+    if has("go.mod"):
+        cmds += ["go vet ./...", "go test ./..."]
+
+    if not cmds and has("Makefile"):
+        mk = "\n" + open(os.path.join(root, "Makefile"), encoding="utf-8", errors="replace").read()
+        cmds += [f"make {t}" for t in ("lint", "typecheck", "test") if f"\n{t}:" in mk]
+
+    return cmds
+
+
+def load_config(path):
+    data = json.load(open(path, encoding="utf-8"))
+    cmds = data.get("commands") if isinstance(data, dict) else data
+    if not isinstance(cmds, list) or not all(isinstance(c, str) for c in cmds):
+        raise SystemExit("gate: --config must hold a list of command strings (or {\"commands\": [...]})")
+    return cmds
+
+
+# --- opt-in harness: a blocking git pre-commit hook (Layer 1) ---------------------------
+# The portable enforcement point — git runs it regardless of which agent/tool wrote the code.
+# Bypassable with `git commit --no-verify`; CI required-checks are the un-bypassable backstop.
+
+def _hooks_dir(root):
+    r = subprocess.run(["git", "rev-parse", "--git-path", "hooks"], cwd=root, capture_output=True, text=True)
+    if r.returncode != 0:
+        raise SystemExit("gate: not a git repository — run --install-hook from inside your repo")
+    hd = r.stdout.strip()
+    return hd if os.path.isabs(hd) else os.path.join(root, hd)
+
+
+def _hook_block(cmd, config):
+    inv = f"python3 {shlex.quote(os.path.abspath(__file__))}"
+    for c in cmd:
+        inv += f" --cmd {shlex.quote(c)}"
+    if config:
+        inv += f" --config {shlex.quote(os.path.abspath(config))}"
+    return (
+        f"# >>> {HOOK_MARKER} >>>  pre-merge-review gate — run `gate.py --uninstall-hook` to remove\n"
+        f"{inv} || {{ echo 'skilldrop-gate: commit blocked (gate RED). Fix it, or override once with "
+        f"--no-verify — CI required-checks still gate the merge.' >&2; exit 1; }}\n"
+        f"# <<< {HOOK_MARKER} <<<\n"
+    )
+
+
+def install_hook(root, cmd, config):
+    hooks = _hooks_dir(root)
+    os.makedirs(hooks, exist_ok=True)
+    path = os.path.join(hooks, "pre-commit")
+    body = open(path, encoding="utf-8").read() if os.path.exists(path) else ""
+    if HOOK_MARKER in body:
+        print(f"gate: hook already installed at {path} — --uninstall-hook then --install-hook to change its commands")
+        return 0
+    if not body.startswith("#!"):
+        body = "#!/bin/sh\n" + body
+    if body and not body.endswith("\n"):
+        body += "\n"
+    body += "\n" + _hook_block(cmd, config)
+    with open(path, "w", encoding="utf-8") as fh:
+        fh.write(body)
+    # chmod +x, not a fixed 0o755: add execute only where the umask already granted read, so a
+    # restrictive umask (077) keeps the hook private instead of being widened to world-readable.
+    mode = os.stat(path).st_mode
+    os.chmod(path, mode | ((mode & 0o444) >> 2))
+    print(f"gate: installed a blocking pre-commit hook -> {path}")
+    print("      a RED gate now blocks `git commit` (any tool). Bypass once with --no-verify; "
+          "wire CI required-checks for the un-bypassable backstop.")
+    return 0
+
+
+def uninstall_hook(root):
+    path = os.path.join(_hooks_dir(root), "pre-commit")
+    if not os.path.exists(path):
+        print("gate: no pre-commit hook to remove")
+        return 0
+    body = open(path, encoding="utf-8").read()
+    new = re.sub(rf"\n?# >>> {HOOK_MARKER} >>>.*?# <<< {HOOK_MARKER} <<<\n?", "\n", body, flags=re.S)
+    if new == body:
+        print(f"gate: no {HOOK_MARKER} block in {path} — left untouched")
+        return 0
+    open(path, "w", encoding="utf-8").write(new)
+    print(f"gate: removed the {HOOK_MARKER} block from {path}")
+    return 0
+
+
+def main():
+    ap = argparse.ArgumentParser(description=__doc__, formatter_class=argparse.RawDescriptionHelpFormatter)
+    ap.add_argument("--cmd", action="append", default=[], help="a verify command (repeatable)")
+    ap.add_argument("--config", help='JSON file: {"commands": [...]}')
+    ap.add_argument("--root", default=".", help="project root (default: cwd)")
+    ap.add_argument("--list", action="store_true", help="print the commands the gate would run, don't run them")
+    ap.add_argument("--install-hook", action="store_true",
+                    help="install a blocking git pre-commit hook that runs this gate (with the given --cmd/--config)")
+    ap.add_argument("--uninstall-hook", action="store_true", help="remove the skilldrop-gate pre-commit hook block")
+    args = ap.parse_args()
+
+    root = os.path.abspath(args.root)
+    if args.uninstall_hook:
+        return uninstall_hook(root)
+    if args.install_hook:
+        return install_hook(root, args.cmd, args.config)
+    cmds = args.cmd or (load_config(args.config) if args.config else detect(root))
+    if not cmds:
+        print("gate: no verify commands — pass --cmd/--config, or run inside a project the gate can "
+              "detect (Python / Node / Go / Makefile).", file=sys.stderr)
+        return 2
+
+    if args.list:
+        print("gate would run, in order:")
+        for c in cmds:
+            print("  -", c)
+        return 0
+
+    results = []
+    for c in cmds:
+        print(f"\n=== gate: {c} ===", flush=True)
+        rc = subprocess.run(c, shell=True, cwd=root).returncode  # operator-supplied commands, by design
+        results.append((c, rc))
+        print(f"--- {'PASS' if rc == 0 else 'FAIL'} ({c}) rc={rc} ---", flush=True)
+
+    print("\n" + "=" * 48)
+    for c, rc in results:
+        print(f"  {'PASS' if rc == 0 else 'FAIL'}  {c}")
+    print("=" * 48)
+
+    failed = [c for c, rc in results if rc != 0]
+    if failed:
+        print(f"GATE: RED — {len(failed)}/{len(results)} command(s) failed. Change is NOT READY to merge.")
+        return 1
+    print(f"GATE: GREEN — all {len(results)} command(s) passed.")
+    return 0
+
+
+if __name__ == "__main__":
+    sys.exit(main())

skilldrop_cli/data/packs/dev-team/skills/release-notes/SKILL.md

@@ -0,0 +1,61 @@
+---
+name: release-notes
+description: Turn git history between two refs into release notes — a customer-facing version written in reader benefits and an internal Keep-a-Changelog version with commit traceability, breaking changes always first. Use when the user wants release notes, a changelog, "what's in this release", a deploy announcement, or to summarize changes since the last tag.
+---
+
+# release-notes
+
+Converts commit history into two artifacts with different readers: **customer-facing release notes** (benefits, no commit-speak) and an **internal changelog** (Keep a Changelog format, every line traceable to a commit). The rule that drives everything: write for the reader who didn't make the change.
+
+## How to respond
+
+1. **Resolve the range.** Default: last tag to HEAD (`git describe --tags --abbrev=0`). If no tags exist, ask for a start ref or take the user's two refs. State the resolved range at the top of the output: "`v1.4.0..HEAD`, 37 commits, 2026-05-02 → 2026-06-10".
+
+2. **Gather the raw material.** `git log <range> --no-merges --pretty='%h|%s|%an|%ad' --date=short` for the commit list; `git log <range> --stat` only when a subject line is too vague to classify. Where the `gh` CLI is available and the repo uses PRs, prefer PR titles over commit subjects (`gh pr list --state merged --search "merged:>={date}"`) — they're written closer to reader language. Don't require `gh`; commits alone are enough.
+
+3. **Classify every change** into Keep-a-Changelog categories plus one local bucket:
+   - **Added / Changed / Fixed / Deprecated / Removed / Security** — reader-visible
+   - **Internal** — refactors, CI, deps, tests; appears in the internal changelog, never in customer notes
+   - **Needs review** — can't tell what it does from the commit; goes in a list for the user, never guessed into customer notes
+
+4. **Hoist breaking changes and migrations to the top** of both artifacts, each with an **Action required** line. A breaking change buried under "Changed" is the cardinal failure of release notes. Detect via `BREAKING`, `!:` conventional-commit markers, migration files, major dependency bumps, and removed public API — and say which signal triggered the flag.
+
+5. **Rewrite, don't transcribe.** Each customer-facing line states what the reader can now do or no longer suffers. ✅ *"Fixed a crash when exporting reports with more than 10,000 rows"* — ❌ *"fix NPE in ReportExporter.flush()"*. Drop ticket numbers and author names from customer notes; keep both in the internal changelog with the short hash on every line.
+
+6. **Emit both artifacts** with [`templates/release-notes.md`](templates/release-notes.md): customer notes first, internal changelog second, then the **Needs review** list. If the user wants only one artifact, emit that one — but the needs-review list is never optional.
+
+## Useful references in this skill
+
+- [`templates/release-notes.md`](templates/release-notes.md) — both artifact skeletons plus the classification cheat-sheet
+
+## Quality bar
+
+- **Breaking changes are first, with an action.** Every breaking entry has "Action required: …" a reader can execute. No action identifiable → it goes to Needs review, not to the top section unverified.
+- **No commit-speak in customer notes.** Class names, function names, internal service names, and ticket IDs are all signals the line wasn't rewritten.
+- **Every internal-changelog line ends in a short hash** (and PR number when available). A claim nobody can trace is a claim nobody can verify.
+- **Internal noise stays internal.** Dependency bumps, refactors, CI, and test-only changes never appear in customer notes — not even as "various improvements".
+- **Nothing is guessed.** A vague commit ("fix stuff", "wip") lands in Needs review with its hash; the skill never invents a user-facing meaning for it.
+- **The range is stated.** Refs, commit count, and date span at the top — so a reader knows exactly what window the notes cover.
+
+## When to use this skill
+
+- ✅ Cutting a release and writing "what's new" for users or customers
+- ✅ Maintaining `CHANGELOG.md` between versions
+- ✅ A deploy/release announcement for internal stakeholders
+- ✅ "Summarize everything merged since the last tag"
+
+## When NOT to use this skill
+
+- ❌ A single PR description — that's one change, just write it
+- ❌ Reviewing the changes for quality or risk — that's `devils-advocate` / `sonar-review`
+- ❌ Stakeholder narrative about *why* the release matters strategically — feed the notes to `exec-summary`
+- ❌ Generating commit messages going forward — this skill reads history, it doesn't write it
+
+## Anti-patterns to avoid
+
+- ❌ **Transcribing commit subjects with bullets in front.** That's `git log` with extra steps — the rewrite into reader language is the entire job.
+- ❌ **"Various bug fixes and improvements."** Either the fix is worth a line or it's internal; the vague catch-all is neither.
+- ❌ **Burying a breaking change** in the middle of "Changed" because the commit didn't shout about it. The detection signals exist precisely for quiet breaks.
+- ❌ **Padding a thin release.** Two real changes get two lines. Inflating with internal noise to look substantial erodes trust in every future release note.
+- ❌ **Marketing adjectives.** "Blazing-fast", "completely redesigned", "supercharged" — state the measurable change ("export is ~3× faster on large reports") or state nothing.
+- ❌ **Silently skipping unparseable commits.** They go to Needs review; the count of skipped commits is part of the output.

skilldrop_cli/data/packs/dev-team/skills/release-notes/evals/eval_queries.json

@@ -0,0 +1,30 @@
+[
+  {
+    "query": "Write release notes for everything since the last tag",
+    "should_trigger": true
+  },
+  {
+    "query": "Update CHANGELOG.md for v3.1 from the git history",
+    "should_trigger": true
+  },
+  {
+    "query": "What's in this release? Turn v1.8.0..v1.9.0 into customer-facing notes",
+    "should_trigger": true
+  },
+  {
+    "query": "Draft a deploy announcement for internal stakeholders from these merged PRs",
+    "should_trigger": true
+  },
+  {
+    "query": "Review the changes in this release for risk before we ship",
+    "should_trigger": false
+  },
+  {
+    "query": "Write a one-page summary for the board on why this release matters strategically",
+    "should_trigger": false
+  },
+  {
+    "query": "Run a Sonar quality review on the code merged this sprint",
+    "should_trigger": false
+  }
+]

skilldrop_cli/data/packs/dev-team/skills/release-notes/evals/evals.json

@@ -0,0 +1,19 @@
+{
+  "skill_name": "release-notes",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "Write release notes for v2.4.0 from this log (range v2.3.0..HEAD, 2026-08-12 to 2026-09-28):\n\na1b2c3d|feat: bulk CSV import for contacts (#412)\ne4f5a6b|fix: NPE in ReportExporter.flush() when >10k rows (#418)\nc7d8e9f|feat!: remove legacy /v1/contacts endpoint (#420)\n0a1b2c3|chore(deps): bump lodash 4.17.20 -> 4.17.21\n4d5e6f7|refactor: extract ExportService\n8a9b0c1|fix stuff\n2d3e4f5|perf: cache tenant settings, report export ~3x faster (#425)",
+      "assertions": [
+        "States the range, commit count (7), and date span at the top",
+        "The removal of /v1/contacts is hoisted to the top of both artifacts with an 'Action required' line and names the !: marker that flagged it",
+        "Customer notes contain no commit-speak — no ReportExporter.flush(), class names, ticket numbers, or author names",
+        "The lodash bump and the ExportService refactor appear only in the internal changelog, never in customer notes, not even as 'various improvements'",
+        "Every internal changelog line ends with its short hash, plus PR number where present",
+        "The vague 'fix stuff' commit (8a9b0c1) goes in the Needs review list with its hash, not guessed into customer notes",
+        "No marketing adjectives; the performance line states the measured change (~3x faster export) rather than 'blazing fast'",
+        "Does not invent features or fixes not present in the log"
+      ]
+    }
+  ]
+}

skilldrop_cli/data/packs/dev-team/skills/release-notes/manifest.json

@@ -0,0 +1,11 @@
+{
+  "name": "release-notes",
+  "version": "0.1.0",
+  "description": "Turn git history between two refs into release notes — a customer-facing version written in reader benefits and an internal Keep-a-Changelog version with commit traceability, breaking changes always first. Use when the user wants release notes, a changelog, \"what's in this release\", a deploy announcement, or to summarize changes since the last tag.",
+  "entrypoint": "SKILL.md",
+  "deps": { "npm": [], "pip": [] },
+  "env": { "required": [], "optional": [] },
+  "related": ["devils-advocate", "exec-summary", "sonar-review"],
+  "tags": ["release-notes", "changelog", "git", "release", "deploy", "communication"],
+  "model": { "tier": "standard", "rationale": "Classifies commits and rewrites them for a reader. The audience translation needs judgment; escalate via large-input on very long ranges." }
+}

skilldrop_cli/data/packs/dev-team/skills/release-notes/templates/release-notes.md

@@ -0,0 +1,83 @@
+# Release-notes templates
+
+Two artifacts, two readers. Customer notes sell nothing and explain everything; the internal changelog trades polish for traceability.
+
+## Artifact 1 — customer-facing release notes
+
+> Note the deliberate rename for a non-technical reader: the Keep-a-Changelog categories **Added → New** and **Changed → Improved** here; Fixed/Security keep their names. The internal changelog (Artifact 2) uses the canonical Keep-a-Changelog headings.
+
+```markdown
+# {Product} {version} — {YYYY-MM-DD}
+
+> Covers {ref}..{ref} · {N} changes
+
+## ⚠ Breaking changes
+
+- **{What broke, in reader terms.}**
+  Action required: {the exact step — config to change, endpoint to migrate, deadline}.
+  (flagged by: {signal — `!:` marker / removed API / migration file})
+
+## New
+
+- {What the reader can now do. One sentence, benefit first.}
+
+## Improved
+
+- {What got better, measurably where possible: "export is ~3× faster on reports over 10k rows".}
+
+## Fixed
+
+- {The symptom the reader no longer suffers: "Fixed a crash when …", "Dates no longer shift by one day when …".}
+
+## Security
+
+- {Reader-relevant statement; severity and affected versions; no exploit detail.}
+```
+
+Rules: no class/function/service names, no ticket IDs, no author names, no "various improvements". A section with nothing in it is deleted, not left empty — except Breaking changes, which when empty becomes the single line "No breaking changes."
+
+## Artifact 2 — internal changelog (Keep a Changelog)
+
+```markdown
+## [{version}] - {YYYY-MM-DD}
+
+Range: `{ref}..{ref}` · {N} commits · {N} PRs
+
+### Added
+- {change} ({#PR}, `{hash}`)
+
+### Changed
+- **BREAKING:** {change + migration step} ({#PR}, `{hash}`)
+- {change} ({#PR}, `{hash}`)
+
+### Fixed
+- {change} ({#PR}, `{hash}`)
+
+### Deprecated / Removed / Security
+- {change} ({#PR}, `{hash}`)
+
+### Internal
+- {refactor / CI / deps / tests — one line each} (`{hash}`)
+```
+
+## Needs review (always emitted, both modes)
+
+```markdown
+## Needs review — {N} commits not classified
+
+| Hash | Subject | Why unclear |
+|---|---|---|
+| `{hash}` | {verbatim subject} | {vague / contradicts diff / can't tell if user-visible} |
+```
+
+## Classification cheat-sheet
+
+| Signal | Bucket |
+|---|---|
+| New endpoint, flag default-on, new UI surface | Added |
+| Behavior or default changed for existing users | Changed (BREAKING if old behavior unobtainable) |
+| `fix:`, bug ticket, regression revert | Fixed |
+| `chore:`, `refactor:`, `test:`, `ci:`, deps, lockfiles | Internal |
+| CVE, auth/authz, input validation, secrets | Security |
+| `feat!:`, `BREAKING CHANGE:`, removed public API, schema migration, major version bump of a public SDK | Breaking — hoist to top |
+| "wip", "fix stuff", "address comments", empty body + vague subject | Needs review |

skilldrop_cli/data/packs/dev-team/skills/sonar-onboard/SKILL.md

@@ -0,0 +1,170 @@
+---
+name: sonar-onboard
+description: Scaffold a repo for Sonar compliance — supports both **SonarQube server** (self-hosted) and **SonarCloud** (SaaS), user picks at setup time. Generates `sonar-project.properties` with language-correct source/test/coverage paths, a CI workflow that runs the scanner on every push and PR and blocks merge on quality-gate failure, and a README snippet documenting the gate. One-shot setup; pair with `sonar-review` for per-change feedback. Use when the user says "set up Sonar", "add SonarQube to this repo", "wire up SonarCloud", "set up the quality gate", or asks to make a project Sonar-compliant for the first time.
+---
+
+# sonar-onboard
+
+Scaffolds the artifacts a repo needs to become Sonar-compliant: a `sonar-project.properties` keyed to the project's actual language and layout, a CI workflow that runs the scanner and enforces the quality gate, and a README block so the next contributor knows what the gate means and how to run a scan locally.
+
+This is a **one-shot setup skill**. For per-change feedback after the repo is onboarded, use [`sonar-review`](../sonar-review/SKILL.md).
+
+Supports both deployment models — the user picks one:
+
+| Mode | When it's right | Host | Key extras |
+|---|---|---|---|
+| **SonarQube server** | Self-hosted, on-prem or in own VPC. Enterprise / regulated orgs. | `https://sonar.<company>.com` (set per-org) | Project token + host URL |
+| **SonarCloud** | SaaS, hosted by SonarSource. Faster setup, no infra. | `https://sonarcloud.io` (fixed) | Project token + **organization key** |
+
+The choice changes three things: the properties file (SonarCloud needs `sonar.organization`), the GitHub Actions step (different action), and the secrets the user must add. Everything else is identical.
+
+## How to respond
+
+1. **Ask which mode** if the user hasn't said — it's the first question. One question, not two:
+
+   > Which Sonar are you using — **SonarQube server** (self-hosted) or **SonarCloud** (SaaS at sonarcloud.io)?
+
+   If they describe the host URL, infer: anything matching `sonarcloud.io` ⇒ SonarCloud; anything else ⇒ SonarQube server. Don't ask twice.
+
+2. **Collect the inputs.** Ask for whichever are missing. Cap at two more clarifying questions per turn; pick defaults for the rest and call them out:
+
+   | Input | Required for | Default if not given |
+   |---|---|---|
+   | **Project key** (e.g. `myorg_payments-api`) | both | `<repo-name>` (derive from `git remote get-url origin`) |
+   | **Organization key** (SonarCloud only, e.g. `my-org`) | SonarCloud | Required — ask if missing |
+   | **SonarQube host URL** (e.g. `https://sonar.company.com`) | SonarQube server | Required — ask if missing |
+   | **Primary language(s)** | both | Detect from repo (see step 3) |
+   | **CI system** | both | GitHub Actions (emit `gitlab-ci`/`jenkins`/`azure-pipelines` only if user names it) |
+   | **Coverage tool** | both | Detect from language (see step 4) |
+
+3. **Detect language(s)** from the working tree — don't ask if a probe will tell you:
+
+   | Marker file | Language | Default source dir |
+   |---|---|---|
+   | `package.json` | JavaScript / TypeScript | `src` |
+   | `pom.xml` | Java (Maven) | `src/main/java` |
+   | `build.gradle` / `build.gradle.kts` | Java / Kotlin (Gradle) | `src/main/java` or `src/main/kotlin` |
+   | `requirements.txt` / `pyproject.toml` / `setup.py` | Python | top-level package dir or `src` |
+   | `go.mod` | Go | repo root |
+   | `*.csproj` / `*.sln` | C# / .NET | project dirs |
+   | `Cargo.toml` | Rust | `src` |
+   | `composer.json` | PHP | `src` |
+   | `Gemfile` | Ruby | `lib` and `app` |
+
+   Multi-language is normal (e.g. TypeScript frontend + Python backend) — set `sonar.sources` to a comma-separated list and emit one combined `sonar-project.properties`. Don't generate one file per language.
+
+4. **Pick the coverage report path** based on language. These are the formats Sonar's importers expect:
+
+   | Language | Coverage report | Sonar property |
+   |---|---|---|
+   | JS / TS | `coverage/lcov.info` (Jest, Vitest default) | `sonar.javascript.lcov.reportPaths` |
+   | Java (Maven) | `target/site/jacoco/jacoco.xml` | `sonar.coverage.jacoco.xmlReportPaths` |
+   | Java (Gradle) | `build/reports/jacoco/test/jacocoTestReport.xml` | `sonar.coverage.jacoco.xmlReportPaths` |
+   | Python | `coverage.xml` (`pytest-cov --cov-report=xml`) | `sonar.python.coverage.reportPaths` |
+   | Go | `coverage.out` | `sonar.go.coverage.reportPaths` |
+   | C# | `coverage.opencover.xml` (coverlet) | `sonar.cs.opencover.reportsPaths` |
+
+   If the user has no coverage tool today, **don't fabricate a report path**. Omit the coverage property and add a `# TODO` comment in the properties file pointing them at the right one.
+
+5. **Generate `sonar-project.properties`** using [`templates/sonar-project.properties.tmpl`](templates/sonar-project.properties.tmpl). Fill placeholders; remove blocks that don't apply.
+
+   **For SonarCloud**, add this line (immediately after `sonar.projectKey`):
+   ```
+   sonar.organization={{ORG_KEY}}
+   ```
+   The organization key is mandatory for SonarCloud and rejected by SonarQube server — emit it for one and not the other.
+
+   **Exclusions** — add these by default; they save the next contributor from a noisy first scan:
+   ```
+   sonar.exclusions=**/node_modules/**,**/dist/**,**/build/**,**/.next/**,**/__pycache__/**,**/*.generated.*,**/vendor/**,**/migrations/**
+   sonar.test.exclusions=**/*.test.*,**/*.spec.*,**/test/**,**/tests/**
+   sonar.coverage.exclusions=**/*.test.*,**/*.spec.*,**/test/**,**/tests/**,**/*.stories.*,**/index.{js,ts}
+   ```
+   Trim language-irrelevant entries (e.g. drop `__pycache__` for a pure-JS repo).
+
+6. **Generate the CI workflow.** Default is GitHub Actions. Pick the template by mode:
+
+   | Mode | Template | Scan action | Gate action |
+   |---|---|---|---|
+   | SonarQube server | [`templates/github-actions-sonar-server.yml.tmpl`](templates/github-actions-sonar-server.yml.tmpl) | `sonarsource/sonarqube-scan-action@v3` | `sonarsource/sonarqube-quality-gate-action@master` |
+   | SonarCloud | [`templates/github-actions-sonarcloud.yml.tmpl`](templates/github-actions-sonarcloud.yml.tmpl) | `SonarSource/sonarcloud-github-action@master` | (built into scan action — `pollingTimeoutSec` controls wait) |
+
+   Both must:
+   - Trigger on `push` to default branch **and** `pull_request` (Sonar needs the PR event to comment on the PR).
+   - Use `actions/checkout@v4` with `fetch-depth: 0` (Sonar needs full history to attribute blame).
+   - Run the project's build + test + coverage **before** the scanner, otherwise coverage is empty.
+   - Reference `SONAR_TOKEN` from GitHub Secrets — never inline.
+
+   Mode-specific:
+   - **Server** also references `SONAR_HOST_URL` from Secrets, and runs a separate `sonarqube-quality-gate-action` step so the job fails on gate failure.
+   - **SonarCloud** doesn't need `SONAR_HOST_URL` (the action defaults to `https://sonarcloud.io`), and references `GITHUB_TOKEN` for PR decoration.
+
+   For GitLab / Jenkins / Azure DevOps, see [`reference.md`](reference.md) — only emit those if the user names them.
+
+7. **Generate the README snippet** using [`templates/readme-snippet.md`](templates/readme-snippet.md). Drop it under a `## Code quality` heading. It documents: what the gate enforces, the two required secrets, the local-scan command, and where to read findings (Sonar UI link).
+
+8. **List the secrets the user must add manually.** End your response with this exact block — the skill cannot set secrets and shouldn't pretend it can. The steps differ by mode:
+
+   **SonarQube server:**
+   ```
+   Manual steps you must do before the workflow runs green:
+   1. Create a SonarQube project at <SONAR_HOST_URL>/projects/create with key `<project-key>`.
+   2. Generate a project token (My Account → Security → Generate Token).
+   3. Add GitHub Secret `SONAR_TOKEN` with the token value.
+   4. Add GitHub Secret `SONAR_HOST_URL` with `<SONAR_HOST_URL>`.
+   5. (Optional) Tighten the Quality Gate in Sonar UI — defaults are listed in the README snippet.
+   ```
+
+   **SonarCloud:**
+   ```
+   Manual steps you must do before the workflow runs green:
+   1. Sign in at https://sonarcloud.io with the GitHub account that owns this repo.
+   2. Create / import the project: + → Analyze new project → pick the repo. Confirm organization is `<org-key>` and project key is `<project-key>`.
+   3. Disable "Automatic Analysis" on the project (Administration → Analysis Method) — the CI-driven scan and Automatic Analysis cannot both run.
+   4. Generate a token (My Account → Security → Generate Token).
+   5. Add GitHub Secret `SONAR_TOKEN` with the token value.
+   6. (Optional) Tighten the Quality Gate in SonarCloud UI — defaults are listed in the README snippet.
+   ```
+
+## Useful references in this skill
+
+- [`templates/sonar-project.properties.tmpl`](templates/sonar-project.properties.tmpl) — properties file skeleton (works for both modes; `sonar.organization` line is SonarCloud-only)
+- [`templates/github-actions-sonar-server.yml.tmpl`](templates/github-actions-sonar-server.yml.tmpl) — CI workflow for self-hosted SonarQube
+- [`templates/github-actions-sonarcloud.yml.tmpl`](templates/github-actions-sonarcloud.yml.tmpl) — CI workflow for SonarCloud
+- [`templates/readme-snippet.md`](templates/readme-snippet.md) — README section for the gate (mode-aware placeholders)
+- [`reference.md`](reference.md) — GitLab / Jenkins / Azure DevOps variants, quality-gate tuning, monorepo guidance, server vs cloud differences
+
+## Quality bar
+
+- **Properties file is keyed to the actual repo.** `sonar.projectKey`, `sonar.sources`, `sonar.tests`, and the coverage path must reflect what's on disk — not a generic example. A properties file that scans the wrong directories produces a green gate that means nothing.
+- **The workflow blocks merge on gate failure.** A scan that runs but doesn't fail PRs is decoration. The `sonarqube-quality-gate-action` step is non-negotiable.
+- **Coverage path exists or is marked TODO.** Pointing at a coverage file that the test step never produces gives Sonar 0% coverage and a false-failing gate. Either wire it up end-to-end or leave it explicit.
+- **`fetch-depth: 0` in checkout.** Shallow clones break Sonar's new-code-period detection. The first scan will look fine; the next ten PRs will mis-attribute issues.
+- **Secrets are referenced, never inlined.** No raw tokens or URLs in committed files. The token belongs in GitHub Secrets; the URL too, even though it's not technically secret — it keeps fork PRs from leaking the host.
+- **README snippet tells the next contributor what the gate enforces.** "Sonar must pass" is not enough — list the conditions (no new bugs, no new vulnerabilities, coverage on new code ≥ X%, duplication ≤ Y%).
+
+## When to use this skill
+
+- ✅ First-time Sonar setup on a repo (server or cloud)
+- ✅ Migrating between modes — SonarCloud → self-hosted (or vice versa). Re-scaffold with the new mode; remember to switch templates *and* the properties file.
+- ✅ Adding Sonar to a fork or a new service in a monorepo (one properties file per module — see `reference.md`)
+- ✅ Replacing an ad-hoc, locally-run scanner setup with a gate-enforcing CI workflow
+
+## When NOT to use this skill
+
+- ❌ Repo already has a working `sonar-project.properties` and a CI workflow that runs the scanner. Use `sonar-review` for per-change feedback instead.
+- ❌ User wants to disable rules or relax the gate to make a failing scan pass. That's a code-quality conversation, not a setup task — push back.
+- ❌ User wants language-specific deep config (custom rule profiles, Sonar plugins, branch analysis tuning). Out of scope; point at [`reference.md`](reference.md) and the Sonar docs.
+- ❌ User wants both SonarQube server *and* SonarCloud scanning the same repo. Pick one — running both means two gates, two histories, and two answers to "did the build pass?".
+
+## Anti-patterns to avoid
+
+- ❌ **Emitting `sonar.organization` for SonarQube server.** It's SonarCloud-only and the server rejects it. Conversely: omitting it for SonarCloud breaks the scan.
+- ❌ **Emitting a `sonar.login=...` line.** Deprecated since Sonar 10. Use `SONAR_TOKEN` env var, which both scan actions read automatically.
+- ❌ **Hard-coding the host URL in the properties file** (server mode). It belongs in CI env / the scan action input, so forks and local runs don't ship someone else's Sonar.
+- ❌ **Forgetting to disable SonarCloud's Automatic Analysis.** The CI scan and Automatic Analysis can't coexist; SonarCloud will fail one of them. The Manual Steps block must include this — it's the #1 cause of "scan ran but didn't update".
+- ❌ **Generating multiple `sonar-project.properties` files for a multi-language single project.** One project = one properties file with comma-separated `sonar.sources`.
+- ❌ **Skipping `pull_request` trigger.** A scan that only runs on `main` finds problems after they're merged — defeats the purpose.
+- ❌ **Inventing a coverage path because "Sonar wants one".** If the project doesn't generate coverage, omit the property and TODO it. A path that points at nothing produces a misleading gate.
+- ❌ **Recommending the user disable rules to pass the gate.** The gate exists to surface real issues. Suggest fixes or scope the gate to "new code" rather than turning rules off.
+- ❌ **Burying the manual steps.** The "Manual steps you must do" block is the most important output — the workflow can't run green without it. Don't summarize it; print it verbatim.

skilldrop_cli/data/packs/dev-team/skills/sonar-onboard/evals/eval_queries.json

@@ -0,0 +1,34 @@
+[
+  {
+    "query": "Set up Sonar for this repo",
+    "should_trigger": true
+  },
+  {
+    "query": "Scaffold sonar-project.properties and the CI workflow",
+    "should_trigger": true
+  },
+  {
+    "query": "Onboard this project onto SonarCloud with a blocking quality gate",
+    "should_trigger": true
+  },
+  {
+    "query": "We want Sonar checks on every PR — configure it",
+    "should_trigger": true
+  },
+  {
+    "query": "Run the Sonar scan and tell me if the gate passes",
+    "should_trigger": false
+  },
+  {
+    "query": "Adversarially review this diff for edge cases",
+    "should_trigger": false
+  },
+  {
+    "query": "Gate my change with lint, tests, and the reviewer panel",
+    "should_trigger": false
+  },
+  {
+    "query": "Design our SLOs and alerting",
+    "should_trigger": false
+  }
+]

skilldrop_cli/data/packs/dev-team/skills/sonar-onboard/evals/evals.json

@@ -0,0 +1,16 @@
+{
+  "skill_name": "sonar-onboard",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "Set this Python repo up for Sonar compliance — we use SonarCloud and run CI on GitHub Actions.",
+      "assertions": [
+        "sonar.projectKey, sonar.sources, sonar.tests and the coverage path reflect what is actually on disk, not generic example values",
+        "The generated CI workflow blocks merge on a quality-gate failure rather than merely running a scan",
+        "SonarCloud vs SonarQube server is chosen explicitly and the generated config matches that choice",
+        "The coverage report path matches the language's real tooling output",
+        "Setup steps that require a token or server-side action are named for the operator rather than silently assumed"
+      ]
+    }
+  ]
+}