@benjaminthomas/spec-driven-dev 1.14.1 → 1.15.0

package/README.md

@@ -294,6 +294,20 @@ Off means every skill ignores risk completely.
 hypothesis: change them under `risk.weights` in `.spec-driven.yml` once you've backtested them
 against your own past bugs.
 
+**Keep the hotspots current on every merge (GitHub Actions).** With a dedicated specs repo on GitHub:
+
+```bash
+spec-driven-dev ci --notify
+```
+
+This writes `.github/workflows/gitrisk.yml` into the specs repo, plus, with `--notify`, a small
+`gitrisk-notify.yml` into each code repo on your machine. When something lands on a repo's base
+branch, it pings the specs repo, which checks out every repo in `team-repos.yml` with full history,
+runs `risk`, and commits the **Risk hotspots** in `CONTEXT.md` only when they changed. A date-only
+change isn't committed. It also runs nightly, and on demand from the Actions tab. You add one secret,
+`GITRISK_TOKEN` (read access to the code repos, write access to the specs repo), and commit the
+workflow files yourself. The command prints the exact steps.
+
 **Does it change what the agent does?** `spec-driven-dev risk-eval --tickets=tickets.md` runs each
 ticket twice, in fresh clones with risk on and off, through investigate and create on the same
 model. It then compares what the agent did:
@@ -646,6 +660,7 @@ spec-driven-dev doctor                            # check .spec-driven.yml again
 spec-driven-dev status                            # list unfinished specs and each one's next step
 spec-driven-dev context --areas=billing           # print the project memory (index, or chosen areas)
 spec-driven-dev settings                          # switch GitRisk, run-through and sharing from a menu
+spec-driven-dev ci --notify                       # GitHub Actions: refresh GitRisk hotspots on every merge
 spec-driven-dev uninstall                         # remove the skills, plugin and cache (--all: settings too)
 spec-driven-dev risk                              # GitRisk: score files from git history → specs/context/risk.md
 spec-driven-dev risk-eval --tickets=tickets.md    # compare agent behaviour with the risk signal on vs off
@@ -760,7 +775,7 @@ skips that step rather than failing.
 
 | Skill | Stage | SKILL.md lines | Words | Supporting files |
 |---|---|---:|---:|---:|
-| `spec-setup` | 0 · configure | 222 | 2,329 | 4 |
+| `spec-setup` | 0 · configure | 273 | 2,829 | 4 |
 | `spec-investigate` | 1 · understand | 387 | 3,367 | 1 |
 | `spec-create` | 2 · plan | 198 | 1,782 | 6 |
 | `spec-implement` | 3 · build | 327 | 2,753 | 3 |
@@ -769,7 +784,7 @@ skips that step rather than failing.
 | `spec-checkpoint` | 6 · commit | 140 | 1,144 | 0 |
 | `spec-ship` | 7 · PR | 230 | 1,388 | 0 |
 | `generative-seo` | standalone | 255 | 2,209 | 7 |
-| **Total** | | **2,059** | **17,823** | **23** |
+| **Total** | | **2,110** | **18,323** | **23** |
 
 - **8** skills: **1** setup + **6** workflow stages + **1** standalone
 - **4** tools supported natively (Claude Code, Codex CLI, Cursor, Antigravity), plus an MCP fallback
@@ -822,7 +837,7 @@ plugin/evals/                 `claude plugin eval` cases
   1. Increase `version` in both `package.json` and `plugin/.claude-plugin/plugin.json` (the check fails if
      they differ).
   2. Add a `CHANGELOG.md` entry, then commit and push.
-  3. Tag the release and push the tag: `git tag v1.14.1 && git push origin v1.14.1`.
+  3. Tag the release and push the tag: `git tag v1.15.0 && git push origin v1.15.0`.
   4. Watch the **publish** run in the repo's Actions tab. When it's green, the new version is on
      npm. Claude Code plugin users get it from the marketplace once the commit is on `main`.
 

package/bin/cli.mjs

@@ -4,6 +4,7 @@
 //
 //   spec-driven-dev                 install the skills, then hand over to your AI tool ("run spec-setup")
 //   spec-driven-dev setup           scripted setup for CI: needs --yes or answer flags (people: say "run spec-setup")
+//   spec-driven-dev ci              write GitHub Actions that refresh GitRisk hotspots on every merge (--notify also writes the per-repo trigger)
 //   spec-driven-dev uninstall       remove the skills (all tools), the Claude Code plugin and the download cache; --all also removes the settings file
 //   spec-driven-dev doctor          check .spec-driven.yml against the real repos (exit 1 on problems)
 //   spec-driven-dev status          list specs with unfinished work and each one's "Resume here" next step
@@ -20,7 +21,7 @@ import path from "node:path";
 import { execFileSync } from "node:child_process";
 import prompts from "prompts";  // arrow-key menus that work in PowerShell, cmd, macOS and Linux terminals
 import { fileURLToPath } from "node:url";
-import { scoreRepo, riskMarkdown, normWeights, weightProblems, setConfigValue } from "./risk.mjs";
+import { scoreRepo, riskMarkdown, normWeights, weightProblems, setConfigValue, riskSummaryBlock, withRiskSummary } from "./risk.mjs";
 import { SHARE_MODES, shareState, planShare, shareTitle } from "./share.mjs";
 
 const ROOT = path.dirname(path.dirname(fileURLToPath(import.meta.url)));
@@ -40,7 +41,7 @@ const args = process.argv.slice(2);
 const flag = (n) => args.includes(`--${n}`);
 const opt = (n) => args.find((a) => a.startsWith(`--${n}=`))?.split("=")[1];
 const command = args.find((a) => !a.startsWith("-")) || "install";
-const YES = flag("yes") || flag("y") || !process.stdin.isTTY || ["doctor", "status", "context", "risk", "risk-eval", "setup"].includes(command) || (command === "uninstall" && flag("yes"));
+const YES = flag("yes") || flag("y") || !process.stdin.isTTY || ["doctor", "status", "context", "risk", "risk-eval", "setup", "ci"].includes(command) || (command === "uninstall" && flag("yes"));
 const DIR = path.resolve(opt("dir") || process.cwd());
 
 // Colour only for a person at a terminal; pipes, CI and NO_COLOR get plain text (and the tests stay plain).
@@ -794,7 +795,10 @@ function loadConfig() {
 }
 
 function risk() {
-  const { root, c } = loadConfig();
+  const loaded = loadConfig();
+  const { root } = loaded;
+  // CI has no personal .spec-driven.yml: --repos and --specs-dir describe the checkout instead.
+  const c = opt("repos") ? { ...loaded.c, layout: "multi-repo", repos: splitList(opt("repos")).map((p) => ({ path: p })), specs_dir: opt("specs-dir") || loaded.c.specs_dir } : loaded.c;
   const bad = weightProblems(c.risk?.weights);
   if (bad.length) throw new Error(bad.join("; "));
   const weights = normWeights(c.risk?.weights), since = opt("since") || c.risk?.since || "2 years ago";
@@ -818,6 +822,11 @@ function risk() {
   const out = path.join(specs, "context", "risk.md");
   fs.writeFileSync(out, riskMarkdown({ rows, repos: scored, weights, since, top: Number(opt("top")) || 40 }));
   ignoreGenerated(out);
+  const ctx = path.join(specs, "CONTEXT.md");
+  if (fs.existsSync(ctx)) {
+    fs.writeFileSync(ctx, withRiskSummary(fs.readFileSync(ctx, "utf8"), riskSummaryBlock(rows, new Date().toISOString().slice(0, 10))));
+    console.log(`  Updated the "Risk hotspots" summary in ${path.relative(DIR, ctx) || ctx}, which is shared with the team.`);
+  }
   const count = (t) => rows.filter((r) => r.tier === t).length;
   console.log(`✓ Scored ${rows.length} files from ${scored.reduce((t, s) => t + s.commits, 0)} commits → ${path.relative(DIR, out) || out}`);
   console.log(`  ${count("critical")} critical · ${count("high")} high · ${count("medium")} medium · ${count("new")} new. Top 5:`);
@@ -933,6 +942,112 @@ async function uninstall() {
   console.log("Done. Reinstall any time with: npx @benjaminthomas/spec-driven-dev@latest");
 }
 
+// ---------- CI: refresh GitRisk hotspots on merge ----------
+function ghSlug(url) { return (String(url || "").match(/github\.com[:/]([^/\s]+\/[^/\s]+?)(?:\.git)?\/?$/) || [])[1] || ""; }
+
+function ciFiles({ specsSlug, repos, version }) {
+  const checkouts = repos.map((r) => `      - uses: actions/checkout@v4
+        with:
+          repository: ${r.slug}
+          path: ${r.name}
+          fetch-depth: 0          # full history: GitRisk reads git log
+          token: \${{ secrets.GITRISK_TOKEN }}`).join("\n");
+  const specs = `# Refreshes the "Risk hotspots" block in CONTEXT.md from every team repo's git history.
+# Written by \`spec-driven-dev ci\`. Re-run that command after adding a repo to team-repos.yml.
+# Needs a repository secret GITRISK_TOKEN: a token that can read the code repos and write to this repo.
+name: GitRisk
+on:
+  repository_dispatch:
+    types: [code-merged]      # sent by each code repo's gitrisk-notify workflow
+  schedule:
+    - cron: "0 3 * * *"       # nightly safety net
+  workflow_dispatch:
+permissions:
+  contents: write
+concurrency:
+  group: gitrisk
+  cancel-in-progress: true
+jobs:
+  score:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+        with:
+          path: specs
+          token: \${{ secrets.GITRISK_TOKEN }}
+${checkouts}
+      - uses: actions/setup-node@v4
+        with:
+          node-version: 20
+      - name: Score files from git history
+        run: npx -y @benjaminthomas/spec-driven-dev@${version} risk --dir=. --repos=${repos.map((r) => r.name).join(",")} --specs-dir=specs
+      - name: Commit when the hotspots changed (not for a date-only change)
+        working-directory: specs
+        run: |
+          git add CONTEXT.md .gitignore
+          if git diff --cached --quiet -I '^Updated [0-9-]+$'; then echo "Hotspots unchanged"; exit 0; fi
+          git -c user.name="gitrisk[bot]" -c user.email="gitrisk@users.noreply.github.com" commit -m "chore: refresh GitRisk hotspots"
+          git push
+`;
+  const notify = (branch) => `# Tells the specs repo to refresh GitRisk hotspots when work lands here.
+# Written by \`spec-driven-dev ci --notify\`. Needs the same GITRISK_TOKEN secret in this repo.
+name: GitRisk notify
+on:
+  push:
+    branches: [${branch}]
+jobs:
+  notify:
+    runs-on: ubuntu-latest
+    steps:
+      - run: gh api repos/${specsSlug}/dispatches -f event_type=code-merged
+        env:
+          GH_TOKEN: \${{ secrets.GITRISK_TOKEN }}
+`;
+  return { specs, notify };
+}
+
+function ci() {
+  const { root, c } = loadConfig();
+  if (!c.layout) throw new Error('No .spec-driven.yml found. Say "run spec-setup" in your AI tool first.');
+  const specs = path.resolve(root, c.specs_dir || "specs");
+  const g = specsInGit(root, c.specs_dir || "specs");
+  if (!g) throw new Error(`${specs} isn't inside a git repo, so there's nowhere to run CI. Keep specs in a repo (a dedicated specs repo is best).`);
+  const specsSlug = ghSlug(run("git", ["remote", "get-url", "origin"], g.top));
+  if (!specsSlug) throw new Error(`The specs repo at ${g.top} has no GitHub remote yet. Push it first, e.g.: gh repo create <org>/<name> --private --source ${g.top} --push`);
+  const team = parseYaml(fs.existsSync(path.join(specs, "team-repos.yml")) ? fs.readFileSync(path.join(specs, "team-repos.yml"), "utf8") : "").repos;
+  const list = (Array.isArray(team) && team.length ? team : (c.repos || []).map((r) => ({ name: path.basename(String(r.path)), url: run("git", ["remote", "get-url", "origin"], path.resolve(root, expandHome(String(r.path)))) })))
+    .map((r) => ({ name: r.name, slug: ghSlug(r.url) })).filter((r) => r.name && r.name !== path.basename(g.top));
+  const missing = list.filter((r) => !r.slug);
+  if (missing.length) throw new Error(`No GitHub URL for ${missing.map((r) => r.name).join(", ")}. Add a "url:" for each in team-repos.yml.`);
+  if (!list.length) throw new Error("No code repos to score. List them in team-repos.yml or your workspace.");
+  const version = JSON.parse(fs.readFileSync(path.join(ROOT, "package.json"), "utf8")).version;
+  const { specs: specsYml, notify } = ciFiles({ specsSlug, repos: list, version });
+  if (g.rel) throw new Error(`Specs live inside ${g.top}, a code repo. The CI step needs a dedicated specs repo, so its commits don't land in a code repo. Move specs with spec-setup, or use: spec-driven-dev risk after merges.`);
+  const wf = path.join(g.top, ".github", "workflows", "gitrisk.yml");
+  fs.mkdirSync(path.dirname(wf), { recursive: true });
+  fs.writeFileSync(wf, specsYml);
+  step(1, "GitRisk on every merge", ink.cyan);
+  console.log(`✓ Wrote ${wf}\n  Scores ${list.map((r) => r.name).join(", ")} nightly, on demand, and whenever a code repo pings it.`);
+  const wrote = [];
+  for (const r of (c.repos || [])) {
+    const dir = path.resolve(root, expandHome(String(r.path)));
+    if (!flag("notify") || !isRepo(dir) || real(dir) === real(g.top)) continue;
+    const branch = r.git?.base_branch && r.git.base_branch !== "default" ? r.git.base_branch : c.git?.base_branch && c.git.base_branch !== "default" ? c.git.base_branch : run("git", ["symbolic-ref", "--short", "refs/remotes/origin/HEAD"], dir).replace(/^origin\//, "") || "main";
+    const f = path.join(dir, ".github", "workflows", "gitrisk-notify.yml");
+    fs.mkdirSync(path.dirname(f), { recursive: true });
+    fs.writeFileSync(f, notify(branch));
+    wrote.push(`${path.basename(dir)} (on ${branch})`);
+  }
+  if (wrote.length) console.log(`✓ Wrote .github/workflows/gitrisk-notify.yml in: ${wrote.join(", ")}`);
+  else console.log("• Add --notify to also write the small trigger workflow into each code repo on this machine, so a merge refreshes the hotspots straight away.");
+  console.log(`
+Next:
+  1. Create a GitHub token (fine-grained): read access to ${list.map((r) => r.name).join(", ")}; contents: read & write on ${specsSlug}.
+  2. Add it as a secret named GITRISK_TOKEN in ${specsSlug}${wrote.length ? " and in each code repo" : ""}:  gh secret set GITRISK_TOKEN -R ${specsSlug}
+  3. Commit and push the workflow file(s). Nothing was committed for you.
+  4. Try it: gh workflow run GitRisk -R ${specsSlug}`);
+}
+
 // Silent unless something is unfinished, so it's cheap to run at the start of a session.
 function status() {
   const file = findConfig(DIR);
@@ -964,6 +1079,7 @@ try {
   else if (command === "risk") risk();
   else if (command === "settings") await settings();
   else if (command === "uninstall") await uninstall();
+  else if (command === "ci") ci();
   else if (command === "risk-eval") await riskEvalCmd();
   else if (command === "install") {
     if (HANDOFF) console.log("No interactive terminal (for example a \"!\" command in Claude Code), so the skills go to the AI tools it finds, for this project.\n");
@@ -971,7 +1087,7 @@ try {
     if (tools.length && !flag("no-setup")) await handOver(tools);
   } else if (SETUP_IN_AGENT) handOver([], true);
   else if (command === "setup") await setup();
-  else throw new Error(`Unknown command "${command}" — use install (default), setup, settings, uninstall, doctor, status, context, risk, or risk-eval`);
+  else throw new Error(`Unknown command "${command}" — use install (default), setup, settings, ci, uninstall, doctor, status, context, risk, or risk-eval`);
   if (command === "setup" && !SETUP_IN_AGENT) console.log('\nNext: in your AI tool, say "investigate <ticket>" or "create a spec".');
 } catch (e) {
   console.error(`✗ ${e.message}`);

package/bin/risk.mjs

@@ -167,3 +167,18 @@ export function setConfigValue(text, blockName, key, value) {
   const body = line.test(block[0]) ? block[0].replace(line, `$1${value}`) : block[0].replace(new RegExp(`^${blockName}:.*\\n`), `$&  ${key}: ${value}\n`);
   return text.replace(block[0], body);
 }
+
+// A short, committed summary inside CONTEXT.md, so the hotspots are part of the shared project memory
+// (risk.md itself is gitignored: it's regenerated on every run). Replaced in place between markers.
+const RB = "<!-- risk:start (written by spec-driven-dev risk; don't edit) -->", RE = "<!-- risk:end -->";
+export function riskSummaryBlock(rows, date) {
+  const top = rows.filter((r) => r.tier === "critical" || r.tier === "high").slice(0, 5);
+  const counts = ["critical", "high", "medium"].map((t) => `${rows.filter((r) => r.tier === t).length} ${t}`).join(" · ");
+  return [RB, "## Risk hotspots", `Updated ${date}`, `${counts}. Full table: context/risk.md (regenerate: spec-driven-dev risk).`,
+    ...(top.length ? top.map((r) => `- \`${r.file}\` ${r.score} ${r.tier}`) : ["- No high or critical files."]), RE].join("\n");
+}
+export function withRiskSummary(text, block) {
+  const i = text.indexOf(RB), j = text.indexOf(RE);
+  if (i >= 0 && j > i) return text.slice(0, i) + block + text.slice(j + RE.length);
+  return `${text.replace(/\n*$/, "")}\n\n${block}\n`;
+}

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@benjaminthomas/spec-driven-dev",
-  "version": "1.14.1",
+  "version": "1.15.0",
   "description": "Spec-driven AI development workflow (investigate → spec → implement → verify → review → ship) as Agent Skills for Claude Code, Cursor, Codex CLI and Antigravity.",
   "type": "module",
   "bin": {

package/plugin/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "ticket-to-pr",
-  "version": "1.14.1",
+  "version": "1.15.0",
   "description": "Parallel-batch spec-driven feature workflow (spec-setup, spec-investigate, spec-create, spec-implement, spec-verify, spec-review, spec-checkpoint, spec-ship) plus a portable SEO/GEO operations skill (generative-seo) for any codebase.",
   "author": {
     "name": "Benjamin Thomas",

package/plugin/skills/spec-setup/SKILL.md

@@ -125,23 +125,74 @@ Read, don't guess. Collect a draft of every field in `references/config-template
 
 ## How to ask
 
-- **Real choices** (layout, keep these repos, sharing, after-approval mode) can be a menu, but only
-  with **two or more** options. A menu with one option is rejected by the tool and the user never
-  sees the question. "Other" doesn't count as an option.
-- **Open questions** (what the product does, fragile spots, direction, unwritten rules, anything
-  else to add) are plain text in **one chat message**. The user answers in their own words or says
-  "skip". Never turn an open question into a menu.
+Two kinds of question, asked two different ways:
+
+1. **Choices** (layout and repos, sharing, specs location, after-approval mode, a guessed command):
+   use the host's **interactive question tool** when it has one (Claude Code: `AskUserQuestion`).
+   - Up to 4 questions per call; each needs **2 to 4 options** (a one-option question is rejected
+     and the user never sees it; "Other" is added automatically and doesn't count).
+   - Put the recommended option first and end its label with "(Recommended)". Put the evidence in
+     each option's description (e.g. "called via BACKBONE_URL, app/services/x.ts:105").
+   - **Layout and repos are two separate calls, always** (Step 2). Never ask layout together with
+     other questions.
+   - **Repos are never offered as preset bundles** ("+backend +melissa", "all four"); bundles don't
+     scale and stop people mixing their own. Ask in two calls:
+     1. **Layout first**, on its own: "Single repo" vs "Several repos that change together"
+        (vs "Monorepo" when it fits), recommendation first with the evidence.
+     2. **Only if several:** a `multiSelect` question with **one option per repo**: label = repo
+        name (the recommended ones first, marked "(Recommended)"), description = what it is plus the
+        link evidence. At most 4 options. The menu can't show the rest, so the **question text** must
+        end by naming the other repos found ("Also found: a, b, c (no code link).") and saying how to
+        add them: "To add any of these, or a repo from another folder, choose *Type something* and
+        enter names or paths, e.g. `a, ~/Work/billing`." Put the remaining choices (specs location,
+        sharing, pipeline) in this same call.
+   - If the tool isn't available (or a call fails), ask the same choices as a short numbered list
+     in text instead. Never drop a question.
+2. **Open questions** (what the product does, fragile spots, direction, unwritten rules): plain text
+   in **one chat message**, asked **after** the choices are answered. Never turn these into a menu.
 
 ## Step 2 — Confirm in one round
 
 Show the draft as a short table grouped by layout, tracker, git, commands, and specs location.
-Mark each value **detected** (with where it came from) or **guess**. Then ask only about guesses
-and conflicts — in one message, not a drip of questions. Typical ones:
-
-- "Your repos default to `master`, but recent PRs targeted `staging`. Cut work from `staging`?"
-- "Recent branches are bare ticket IDs (`STP-282`). Keep that, or use `fix/STP-282-short-slug`?"
-- "These 6 repos share the `acme` GitHub org. Do they form one workspace for the pipeline?"
-- "Where should specs live — this folder's `specs/`, or inside one repo so they go through PRs?"
+Mark each value **detected** (with where it came from) or **guess**. Then ask in exactly this order
+(interactive question tool when there is one; see How to ask):
+
+**Call 1: layout, alone. Nothing else in this call.** Use these option labels exactly; no repo names
+in them:
+- `Single repo`: "Only <this repo>." (+ the evidence for or against)
+- `Several repos`: "<this repo> changes together with other repos. You'll pick which next."
+- `Monorepo`: only when workspace markers were found.
+
+Recommend one (first, with "(Recommended)") and put the evidence in the question text.
+
+**Call 2: repos (only if the answer was `Several repos`).** The repo tick-box list (`multiSelect`, one
+option per repo, see `references/repo-picker.md`) and where specs live (a dedicated specs repo, inside
+one code repo, or this machine only).
+
+**Call 3: git conventions, always, even when detected.** These decide how every branch and commit is
+made, and detection can be wrong, so confirm them. Four questions, the detected value first with its
+evidence in the description, then the common alternatives:
+- **Base branch** (work starts from): e.g. `staging (Recommended)`: "16 of the last 20 merged PRs";
+  `main`; `develop`. In multi-repo, say which repos differ ("staging; soreto-cms has none, uses main").
+- **PR target**: usually the same as the base branch.
+- **Branch names**: e.g. `STP-123 (Recommended)` (bare ticket id, seen in recent branches);
+  `feat/STP-123-short-name`; `feat/short-name`.
+- **Commit style**: e.g. `STP-123: message (Recommended)`; `feat: message`; free text. In multi-repo,
+  name any repo that uses a different style.
+
+**Call 4: tracker, team and pipeline.** The tracker, confirmed like the git conventions (e.g.
+`Jira, key STP (Recommended)`: "STP-123 in recent branches", `GitHub Issues`, `Linear`, `None`), then
+sharing (if specs are inside a repo), after approval (stop / run straight through), and any command
+that's a guess (e.g. typecheck). At most 4; a guessed command that doesn't fit goes in the summary as
+"I'll use X, say if that's wrong".
+
+Then the open questions, as plain text (see How to ask).
+
+Typical things to flag in the descriptions:
+
+- "Your repos default to `master`, but recent PRs targeted `staging`."
+- "Recent branches are bare ticket IDs (`STP-282`)."
+- "These 6 repos share the `acme` GitHub org."
 
 If the user says "just use the defaults", accept the detected values and the template defaults
 for the rest.

package/plugin/skills/spec-setup/references/audit.md

@@ -41,7 +41,8 @@ never ask again.
 ## 3. Discovery questions (one round)
 
 Show the draft map first, with each line marked **detected** (with its source) or **guess**. Then
-ask only what the code can't answer, as **plain text in one message**. These are open questions, so
+ask only what the code can't answer, as **plain text in one message**, after the setup choices have
+been answered. These are open questions, so
 never put them in a menu or multiple-choice tool (a menu needs two or more real options, and these
 have none). The user replies in their own words, or "skip":
 

package/plugin/skills/spec-setup/references/context-template.md

@@ -54,8 +54,18 @@ Project: existing · audited at a1b2c3d (2026-11-10) · graph: none
 
 ## Specs
 - {stp-123: retry failed webhooks, touched billing (2026-11-10)}
+
+<!-- risk:start (written by spec-driven-dev risk; don't edit) -->
+## Risk hotspots
+GitRisk on 2026-11-10: 0 critical · 8 high · 30 medium. Full table: context/risk.md (regenerate: spec-driven-dev risk).
+- `app/services/billing.ts` 61.7 high
+<!-- risk:end -->
 ```
 
+The **Risk hotspots** block is written by `spec-driven-dev risk` (setup, every batch, checkpoint) and
+replaced in place, so don't edit it. It's the shared part of GitRisk: `context/risk.md` itself is
+gitignored because it's regenerated on every run.
+
 ## context/<area>.md
 
 ```markdown

package/plugin/skills/spec-setup/references/repo-picker.md

@@ -52,6 +52,11 @@ Group the candidates:
   with this one. Some systems connect only through a shared database or a message queue the code
   doesn't name.
 
+Ask it with the host's interactive question tool when there is one: after the layout question, a
+`multiSelect` question with **one option per repo** (never bundles of repos), the recommended ones
+first, evidence in each option's description, 2–4 options. End the question text with the other
+repos found by name and how to add them ("choose *Type something* and enter names or paths, e.g.
+`old-admin, ~/Work/billing`"), since the menu only shows 4. Otherwise as text.
 Shape of the question, with placeholders rather than real names:
 
 > I found 6 repos under ~/code/github.com/acme. Based on the code, I'd include: