@benjaminthomas/spec-driven-dev 1.14.0 → 1.14.1

package/README.md

@@ -150,7 +150,7 @@ before it writes the file. If any skill finds no config, it runs this setup firs
 | What it asks | Detected from | Example answer |
 |---|---|---|
 | How the project is organised | git repos and workspace files (`pnpm-workspace.yaml`, `turbo.json`, `nx.json`, `go.work`, …). A Shopify app's `extensions/` count as one app | `single`, `monorepo`, or `multi-repo` |
-| *multi-repo:* which repos you work on | git repos nearby, grouped by GitHub owner, plus the team's `team-repos.yml` | `soreto-shopify, reverb-backend` |
+| *multi-repo:* which repos you work on | each repo's purpose, evidence of how it connects to this one (env vars, API calls, docs), your recent commits, and `team-repos.yml`; it recommends a selection with reasons | `soreto-shopify, reverb-backend` |
 | *multi-repo:* where specs live | (you choose) | a dedicated specs repo, a code repo, or this machine only |
 | Issue tracker | ticket keys in branch names and commits | Jira, key `STP` |
 | Base branch / PR target | default branch, `staging`/`develop`, recent PR targets | `staging` |
@@ -760,7 +760,7 @@ skips that step rather than failing.
 
 | Skill | Stage | SKILL.md lines | Words | Supporting files |
 |---|---|---:|---:|---:|
-| `spec-setup` | 0 · configure | 210 | 2,201 | 3 |
+| `spec-setup` | 0 · configure | 222 | 2,329 | 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 +769,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,047** | **17,695** | **22** |
+| **Total** | | **2,059** | **17,823** | **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 +822,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.0 && git push origin v1.14.0`.
+  3. Tag the release and push the tag: `git tag v1.14.1 && git push origin v1.14.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/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@benjaminthomas/spec-driven-dev",
-  "version": "1.14.0",
+  "version": "1.14.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.14.0",
+  "version": "1.14.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-setup/SKILL.md

@@ -51,10 +51,13 @@ Read, don't guess. Collect a draft of every field in `references/config-template
      multi-repo workspace). The same goes for any repo whose "packages" are plug-ins of one app.
    - **Ask when one repo works with others.** Even inside a single repo, ask once: "Does this repo
      change together with other repos (for example a backend)?" A yes means `multi-repo`.
-   - Not inside a git repo, but sibling folders are git repos → candidate `multi-repo`. Group them
-     by remote owner (`git remote get-url origin`) and show the groups — the user picks which repos
-     belong together. Never assume every folder in the parent belongs. Always also ask whether
-     repos in **other folders** belong (e.g. `~/clients/billing`). Check each path is a git repo,
+   - Not inside a git repo, but sibling folders are git repos → candidate `multi-repo`.
+   - **Choosing the repos is a required question for `multi-repo`, never a detection.** Someone new
+     doesn't know what `soreto-melissa` is, so never show bare folder names. Follow
+     `references/repo-picker.md`: say what each candidate repo is, show evidence of how it connects
+     to the current repo, note whether the user commits to it, and recommend a selection with a
+     reason per repo. Ask once, and don't write the config until they've answered. Always also
+     offer repos in **other folders** (e.g. `~/clients/billing`). Check each path is a git repo,
      and store paths inside the workspace as relative and paths outside it as absolute.
    - The repos of one workspace can live in unrelated places (`/Projects/frontend`,
      `~/Work/backend`, `/srv/database`). Put the config in their shared parent folder, or in
@@ -120,6 +123,15 @@ Read, don't guess. Collect a draft of every field in `references/config-template
    Store the answer as `context.share`. A dedicated specs repo is shared by nature: set
    `context.share: all`.
 
+## 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.
+
 ## Step 2 — Confirm in one round
 
 Show the draft as a short table grouped by layout, tracker, git, commands, and specs location.

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

@@ -41,7 +41,9 @@ 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, in one message:
+ask only what the code can't answer, as **plain text in one message**. 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":
 
 - What does the product do, and who uses it?
 - Which areas are legacy, frozen, or off-limits?

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

@@ -0,0 +1,74 @@
+# Choosing the repos of a multi-repo workspace
+
+People can't choose from folder names alone, and every team's machine looks different. Do the
+homework first, then recommend a selection with reasons. Work from evidence, never from the names.
+
+## 1. Find candidates (any folder layout)
+
+- Git repos below the workspace folder. Start two levels down; go deeper only when the layout calls
+  for it (`~/code/github.com/<org>/<repo>`, `~/work/<client>/<repo>`). Skip worktrees (their `.git`
+  is a file), `node_modules`, vendor and build folders.
+- Repos in `{specs_dir}/team-repos.yml` if it exists, including ones not cloned here.
+- Repos the user names from other folders, and git submodules of the current repo.
+- **Lots of repos?** Don't list them all. Rank by the evidence below and show the top 8 or so, then
+  "N other repos found, name any you want added".
+
+## 2. For each candidate, gather (cheap commands; read only what's needed)
+
+**What it is**, in one line. The first that exists:
+1. `team-repos.yml` role.
+2. README's first heading and paragraph. Skip boilerplate from a framework template.
+3. Manifest description: `package.json`, `pyproject.toml`, `Cargo.toml`, `go.mod` module path,
+   `pom.xml`/`build.gradle` artifact, `composer.json`.
+4. `AGENTS.md`/`CLAUDE.md` first lines.
+5. Its shape: main folders and entry point (e.g. "a Go service with `cmd/worker`").
+
+**How it connects to the current repo.** Search the current repo (and the candidate) for any of
+these, and quote one piece of evidence with `path:line`:
+
+| Link | What to look for |
+|---|---|
+| Runtime calls | the candidate's name, hostnames, base-URL env vars, API paths, in code, `.env.example`, config |
+| Contracts | OpenAPI/Swagger clients, GraphQL schemas, gRPC/protobuf files, generated SDKs naming the other service |
+| Packages | one repo depends on the other's package (npm, PyPI, Go module, Maven, NuGet, internal registry) |
+| Infrastructure | `docker-compose` services, Kubernetes/Helm manifests, Terraform, CI jobs that check out the other repo |
+| Messages and data | queue or topic names, event names, a shared database or schema both mention |
+| Code layout | git submodules, shared generated code, copied types |
+| Docs | `README`, `AGENTS.md`, architecture docs saying "calls X" or "consumed by Y". A passing mention ("unlike X") is not a link |
+
+**Whether the user works on it:** `git log --since=90.days --author="$(git config user.email)"
+--oneline | wc -l`. Use it as a hint only. A new team member has no commits anywhere, so recommend
+from code links and `team-repos.yml` alone, and don't mention commits.
+
+**Owner:** `git remote get-url origin`. Same organisation is weak evidence, never enough alone.
+
+## 3. Recommend, then ask once
+
+Group the candidates:
+- **I'd include**: the current repo, plus repos with a real link (any row above). Give the reason
+  and the evidence for each.
+- **Probably not needed for this repo**: the rest, each with a short why ("no link found").
+- **No links found at all?** Say so plainly and ask the user to describe which repos change together
+  with this one. Some systems connect only through a shared database or a message queue the code
+  doesn't name.
+
+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:
+> - ✓ **orders-api**: this repo, the orders REST service (FastAPI)
+> - ✓ **payments-worker**: a Go worker. `docker-compose.yml:31` runs it next to this API, and both
+>   use the `payment.requested` queue (`app/events.py:12`)
+> - ✓ **storefront-web**: React app. Its generated client `src/api/orders.ts` is built from this
+>   repo's OpenAPI spec
+>
+> Probably not needed for this repo:
+> - **design-tokens**, **marketing-site**, **old-admin**: no link to orders-api found
+>
+> Keep these three, or add any of the others (or a repo from another folder)? You can change this
+> any time: "add old-admin to the workspace".
+
+Rules:
+- Never pick for the user silently, and never include a repo because it's in the same folder.
+- Someone new should be able to answer "yes". An expert can adjust.
+- Fewer repos is better: investigations search every listed repo, so extra ones cost tokens.
+- Write nothing until they answer, and show the chosen repos again in the final summary.