@benjaminthomas/spec-driven-dev 1.13.0 → 1.13.1

package/README.md

@@ -741,7 +741,7 @@ skips that step rather than failing.
 | Skill | Stage | SKILL.md lines | Words | Supporting files |
 |---|---|---:|---:|---:|
 | `spec-setup` | 0 · configure | 210 | 2,201 | 3 |
-| `spec-investigate` | 1 · understand | 385 | 3,325 | 1 |
+| `spec-investigate` | 1 · understand | 387 | 3,367 | 1 |
 | `spec-create` | 2 · plan | 198 | 1,782 | 6 |
 | `spec-implement` | 3 · build | 327 | 2,753 | 3 |
 | `spec-verify` | 4 · prove | 163 | 1,557 | 1 |
@@ -749,7 +749,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,045** | **17,653** | **22** |
+| **Total** | | **2,047** | **17,695** | **22** |
 
 - **8** skills: **1** setup + **6** workflow stages + **1** standalone
 - **4** tools supported natively (Claude Code, Codex CLI, Cursor, Antigravity), plus an MCP fallback
@@ -802,7 +802,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.13.0 && git push origin v1.13.0`.
+  3. Tag the release and push the tag: `git tag v1.13.1 && git push origin v1.13.1`.
   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

@@ -167,17 +167,24 @@ async function install() {
 // happen in the AI tool. Claude Code and Codex can be opened with the request already typed in.
 const LAUNCHERS = [["claude", "Claude Code"], ["codex", "Codex"]];
 async function handOver(tools, onlySetup) {
+  // The folder says where the AI tool opens; "project" says what gets set up (it can span several repos).
   const name = path.basename(gitTop(DIR));
-  step(onlySetup ? 1 : 2, `Set up ${name} in your AI tool`, ink.magenta);
-  console.log(`
-${onlySetup ? "Setup happens in your AI tool now, so it can read the code and you can change any answer as you go." : "Skills installed."}
-Next: set up ${name}. In your AI tool, say "run spec-setup". It asks how the project is organised
-(single repo, monorepo, or several repos), your tracker, branches and whether to share specs,
-then looks through the code. Start a new session if your tool doesn't recognise it yet.${onlySetup ? `
-For scripts and CI: spec-driven-dev setup --yes [--layout=… --repos=… --share=…]` : ""}`);
-  const launcher = LAUNCHERS.find(([bin]) => (onlySetup || tools.includes(bin)) && onPath(bin));
-  if (!launcher || !process.stdin.isTTY || YES || onlySetup) return;
-  if (!(await askConfirm(`Open ${launcher[1]} here now and start it? (takes a few minutes, uses your ${launcher[1]} plan)`, true))) return;
+  const what = "It first asks how your project is organised: one repo, a monorepo, or several repos that change together.";
+  const next = `Next: in ${name}, open your AI tool and say "run spec-setup".\n${what}
+Then it asks about your tracker, branches and sharing, and looks through the code.
+Start a new session if your tool doesn't recognise it yet.`;
+  step(onlySetup ? 1 : 2, "Set up your project in your AI tool", ink.magenta);
+  if (onlySetup) {
+    console.log(`Setup happens in your AI tool now, so it can read the code and you can change any answer as you go.\n${next}\nFor scripts and CI: spec-driven-dev setup --yes [--layout=… --repos=… --share=…]`);
+    return;
+  }
+  const launcher = LAUNCHERS.find(([bin]) => tools.includes(bin) && onPath(bin));
+  if (!launcher || !process.stdin.isTTY || YES) { console.log(`Skills installed.\n${next}`); return; }
+  // The question carries the explanation, so there's no paragraph to read twice.
+  if (!(await askConfirm(`Open ${launcher[1]} in ${name} to set up your project? ${what} (A few minutes, on your ${launcher[1]} plan.)`, true))) {
+    console.log(next);
+    return;
+  }
   const { spawnSync } = await import("node:child_process");
   spawnSync(launcher[0], ["run spec-setup"], { cwd: DIR, stdio: "inherit" });
 }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@benjaminthomas/spec-driven-dev",
-  "version": "1.13.0",
+  "version": "1.13.1",
   "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.13.0",
+  "version": "1.13.1",
   "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-investigate/SKILL.md

@@ -84,12 +84,14 @@ Use it only when `.spec-driven.yml` has `risk.enabled: on`, or has no `risk:` bl
 file, compute scores, or mention risk. That keeps on/off comparisons (`spec-driven-dev risk-eval`)
 clean.
 
-1. Once you know the change surface, look up its files: `spec-driven-dev risk --files=a,b` (or
+1. **Required, not optional:** once you know the change surface, and before writing the report, look up its files: `spec-driven-dev risk --files=a,b` (or
    `npx -y @benjaminthomas/spec-driven-dev risk --files=…`), or find them in `risk.md`. Without the
    CLI, approximate a file's history with `git log --since="2 years ago" --format=%s -- <file>`.
 2. For each **high** or **critical** file in the surface, look harder: read its last ~10 commit
    subjects and the diffs of its last 1–2 fix commits, and check its dependents. Write what keeps
    breaking there in the report's **Risk Hotspots** section.
+   The report's **Risk Hotspots** section must exist when risk is on: list the high/critical files,
+   or write "none of the touched files are high or critical (checked)" so a reader knows it was done.
 3. A score is a reason to look harder, never evidence. Hotspot findings still need their
    VERIFIED / INFERRED labels.
 4. **New files** (added in the last 90 days with fewer than 3 commits, or not committed yet) show as tier `new`: too little