@ericrisco/rsc 0.1.25 → 0.1.27

package/README.md

@@ -32,6 +32,30 @@ npx @ericrisco/rsc            # plain-language wizard — no jargon, installs wh
 
 ---
 
+## 🤖 For agents: "install this harness"
+
+If you're an AI coding agent (Claude Code, Cursor, Copilot, Codex, Gemini…) and your user
+asked you to **install rsc / this harness / these skills**, run this in the **root of the
+project they're equipping** — not inside a clone of this repo (see the note under *Install*):
+
+```bash
+npx @ericrisco/rsc@latest
+```
+
+That launches a plain-language wizard: it asks **which assistants** to target and **what the
+user wants**, reads the repo, then installs the floor (`orient` + `rsc-suggest` + `harness` +
+`init`) plus only the skills that fit — one at a time. No global install and no API key needed.
+
+- **Choose assistants non-interactively:** `npx @ericrisco/rsc@latest --target claude` (comma-separate for several).
+- **Already installed, just refreshing skills + hooks:** `rsc sync` (or re-run the command above).
+- **Add one skill by id:** `rsc add <id>` · **browse the catalog:** `rsc consult "<what you want>"` or `rsc list`.
+
+From then on it's self-driving: `rsc-suggest` proposes the next skill as tasks appear, and in
+Claude Code a hook re-asserts the spec-first **new-feature gate** on every turn — so a feature
+request routes through `specify` before any skill writes code.
+
+---
+
 ## Why this exists
 
 Most skill packs dump hundreds of files into your context and call it a day. This
@@ -86,8 +110,10 @@ The first run asks **which assistants** you want — Claude Code, Codex, Copilot
 Cursor, Gemini, Windsurf, Cline and 11 more (pick any combination) — and installs
 the **floor**:
 `orient` + `rsc-suggest` (always-on) + `harness` + `init`. In Claude Code it
-also wires a `SessionStart` hook so your assistant proposes new skills on its
-own from then on.
+also wires a `SessionStart` hook (so your assistant proposes new skills on its
+own) and a `UserPromptSubmit` hook that re-asserts the **SDD new-feature gate**
+on every turn — so a feature request, in any language, routes through `specify`
+first, before any skill writes code. Opt out per project with `.rsc/.no-feature-gate`.
 
 Everything stays **in the project**, and the real skill files are written
 **once** to `.rsc/skills/<id>/`. Each assistant you pick gets a lightweight

package/manifest.json

@@ -1,5 +1,5 @@
 {
-  "version": "0.1.25",
+  "version": "0.1.27",
   "counts": {
     "skills": 231
   },
@@ -3666,7 +3666,7 @@
     },
     {
       "id": "sdd",
-      "description": "Use when you want a disciplined, spec-driven path from a feature idea to shipped, verified software — the rsc-sdd dispatcher / front door. It states the SDD method, reads the accompaniment dial from 02-DOCS, and routes to the right phase skill: constitution -> specify -> clarify -> plan -> tasks -> analyze -> implement -> verify -> review -> ship, with debug / worktrees / parallel callable on demand. Use it to START a feature, when unsure which SDD phase you are in, or to govern the whole flow. Triggers: 'spec-driven development', 'sdd', 'build this feature properly', 'start a new feature', 'I have an idea, take it to production', 'which phase am I in', 'run the sdd flow', 'desarrollo dirigido por especificación', 'monta esta feature bien', 'de la idea a producción', 'per-phase model routing', 'use a cheaper model for implementation', 'qué modelo por fase'. NOT itself a single phase (it dispatches), NOT the workspace harness (harness), NOT a stack build skill.",
+      "description": "Use when you want a disciplined, spec-driven path from a feature idea to shipped, verified software — the rsc-sdd dispatcher / front door. It states the SDD method, reads the accompaniment dial from 02-DOCS, and routes to the right phase skill: constitution -> specify -> clarify -> plan -> tasks -> analyze -> implement -> verify -> review -> ship, with debug / worktrees / parallel callable on demand. Use it to START a feature, when unsure which SDD phase you are in, or to govern the whole flow. Triggers: 'spec-driven development', 'sdd', 'build this feature properly', 'start a new feature', 'I have an idea, take it to production', 'which phase am I in', 'run the sdd flow', 'desarrollo dirigido por especificación', 'monta esta feature bien', 'munta aquesta feature bé', 'de la idea a producción', 'de la idea a producció', 'fem un SDD per X', 'quina fase soc', 'per-phase model routing', 'use a cheaper model for implementation', 'qué modelo por fase'. NOT itself a single phase (it dispatches), NOT the workspace harness (harness), NOT a stack build skill.",
       "tags": [
         "sdd",
         "spec",
@@ -3971,7 +3971,7 @@
     },
     {
       "id": "specify",
-      "description": "Use when a feature, change, or product idea is still fuzzy and needs brainstorming into an APPROVED spec BEFORE any planning or code — the brainstorming front door of SDD. Turns a one-line intent into a WHAT/WHY spec (problem, goals, users, scope, behaviour, acceptance) with zero implementation detail, via one-question-at-a-time dialogue, 2-3 proposed approaches with a recommendation, and a design the user approves before anything gets built. Triggers: 'write a spec for…', 'spec this out', 'brainstorm this feature', 'especifica esta feature', 'I want to add X', 'tengo una idea', 'se me ha ocurrido', '¿y si…?', 'wouldn't it be nice if…', 'let's think this through', 'what should this feature do', 'draft a PRD', or any moment someone jumps to HOW before WHAT is agreed. NOT the technical plan (that's `plan`), NOT the de-risking ambiguity sweep (that's `clarify`), NOT project-wide principles (that's `constitution`).",
+      "description": "Use when a feature, change, or product idea is still fuzzy and needs brainstorming into an APPROVED spec BEFORE any planning or code — the brainstorming front door of SDD. Turns a one-line intent into a WHAT/WHY spec (problem, goals, users, scope, behaviour, acceptance) with zero implementation detail, via one-question-at-a-time dialogue, 2-3 proposed approaches with a recommendation, and a design the user approves before anything gets built. Triggers: 'write a spec for…', 'spec this out', 'brainstorm this feature', 'especifica esta feature', 'm'agradaria afegir/posar X', 'voldria…', 'vull afegir/fer X', 'es podria afegir…', 'estaria bé que…', 'i si…?', 'I want to add X', 'tengo una idea', 'se me ha ocurrido', '¿y si…?', 'wouldn't it be nice if…', 'let's think this through', 'what should this feature do', 'draft a PRD', or any moment someone jumps to HOW before WHAT is agreed. NOT the technical plan (that's `plan`), NOT the de-risking ambiguity sweep (that's `clarify`), NOT project-wide principles (that's `constitution`).",
       "tags": [
         "sdd",
         "spec",

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@ericrisco/rsc",
-  "version": "0.1.25",
+  "version": "0.1.27",
   "description": "Eric Risco's agent-skills catalog as a granular, self-recommending CLI installer.",
   "type": "module",
   "bin": {

package/scripts/install-apply.js

@@ -14,22 +14,37 @@ const CLI_VERSION = JSON.parse(readFileSync(join(ROOT, 'package.json'), 'utf8'))
 // materialized at — the single, target-agnostic source of truth for "installed
 // skills version" (read by the SessionStart update check too).
 const versionFile = (cwd) => join(cwd, '.rsc', '.version');
-function readBaseVersion(cwd) {
-  try { return readFileSync(versionFile(cwd), 'utf8').trim(); } catch { return undefined; }
+
+// Per-skill base version. A single global `.rsc/.version` cannot represent a
+// partially-refreshed base set, which broke multi-target sync: the first target's pass
+// bumped `.rsc/.version`, so later targets saw "current" and skipped refreshing their
+// exclusive skills' bases. Tracking the version each base was materialized at makes the
+// refresh decision per skill, independent of target ordering. (Absent file → every base
+// is treated as stale and refreshed once, which self-heals installs from before this.)
+const baseVersionsFile = (cwd) => join(cwd, '.rsc', '.base-versions.json');
+function readBaseVersions(cwd) {
+  try { return JSON.parse(readFileSync(baseVersionsFile(cwd), 'utf8')); } catch { return {}; }
+}
+function writeBaseVersions(cwd, versions) {
+  mkdirSync(dirname(baseVersionsFile(cwd)), { recursive: true });
+  writeFileSync(baseVersionsFile(cwd), JSON.stringify(versions, null, 2) + '\n');
 }
 
-// Materialize the real skill files into the project-local base. Normally copied
-// once and reused; when `refresh` is set (a different CLI version than the base was
-// materialized at) the base is re-copied so a reinstall actually updates content.
-// Skills are read-only catalog (user customization lives in 02-DOCS/CLAUDE.md), so
-// overwriting on a version change is safe.
-function ensureBase(id, cwd, refresh) {
+// Materialize the real skill files into the project-local base. Copied once and reused;
+// when the recorded base version for THIS skill differs from the CLI version, the base is
+// re-copied so a reinstall/sync actually updates content. Tracked per skill (see
+// baseVersionsFile) so a multi-target sync refreshes every target's bases, not just the
+// first target's. Skills are read-only catalog (user customization lives in 02-DOCS), so
+// overwriting on a version change is safe. Mutates `baseVersions` with the new mark.
+function ensureBase(id, cwd, baseVersions) {
   const dest = baseDir(id, cwd);
-  if (refresh && existsSync(dest)) rmSync(dest, { recursive: true, force: true });
+  const stale = baseVersions[id] !== CLI_VERSION;
+  if (stale && existsSync(dest)) rmSync(dest, { recursive: true, force: true });
   if (!existsSync(dest)) {
     mkdirSync(dirname(dest), { recursive: true });
     cpSync(join(ROOT, 'skills', id), dest, { recursive: true });
   }
+  baseVersions[id] = CLI_VERSION;
   return dest;
 }
 
@@ -46,7 +61,7 @@ function generatedHookFiles({ target, cwd }) {
 function managedPathsForInstall({ skillIds, target, home, cwd }) {
   const paths = targetPaths(target, home, cwd);
   const plan = planInstall({ skillIds, target, home, cwd });
-  const out = [paths.stateFile, versionFile(cwd)];
+  const out = [paths.stateFile, versionFile(cwd), baseVersionsFile(cwd)];
   for (const step of plan) {
     if (step.kind === 'skill') {
       out.push(step.to, baseDir(step.id, cwd));
@@ -64,18 +79,21 @@ export async function applyInstall({ skillIds, target, home, cwd = process.cwd()
   if (dryRun) return { dryRun: true, skills: skillIds, paths: managedPaths };
   const state = readState(paths.stateFile);
   const backup = createBackup({ cwd, operation, target, paths: managedPaths, cliVersion: CLI_VERSION });
-  // Refresh bases when installing a different version than they were materialized at
-  // (or a pre-versioning install where the marker is absent). Same version → no-op.
-  const refresh = readBaseVersion(cwd) !== CLI_VERSION;
+  // Decide base refresh per skill (see baseVersionsFile): a base is re-materialized when
+  // its recorded version differs from the CLI version. Robust to multi-target installs/
+  // syncs — a single global marker would be bumped by the first target and make later
+  // targets skip refreshing their exclusive skills' bases.
+  const baseVersions = readBaseVersions(cwd);
   for (const step of plan) {
     if (step.kind === 'skill') {
-      const base = ensureBase(step.id, cwd, refresh);
+      const base = ensureBase(step.id, cwd, baseVersions);
       const files = await writeSkill(target, step.id, base, step.to);
       state.skills[step.id] = { files, base };
     } else if (step.kind === 'hook') {
-      await wireHook(target, paths, join(ensureBase('suggest', cwd, refresh), 'SKILL.md'));
+      await wireHook(target, paths, join(ensureBase('suggest', cwd, baseVersions), 'SKILL.md'));
     }
   }
+  writeBaseVersions(cwd, baseVersions);
   state.version = CLI_VERSION;
   writeState(paths.stateFile, state);
   mkdirSync(dirname(versionFile(cwd)), { recursive: true });

package/skills/building-agents/SKILL.md

@@ -18,6 +18,8 @@ Build production LLM agents that are model-agnostic by construction — a thin p
 
 ## When to use / When NOT to use
 
+> **⚠️ SDD new-feature gate — read this first.** If this skill fired on a **new, non-trivial feature or behaviour change** and there is **no approved spec + plan** under `02-DOCS/wiki/sdd/`, STOP — do **not** write feature code yet. Hand off to `../specify/SKILL.md` first: it runs brainstorm → spec → plan → tasks before any code, then routes back here once the plan is approved. Build here directly only for a genuinely one-line / low-risk change. Method: `../sdd/SKILL.md`.
+
 **Use when:** starting any production-bound LLM feature; code is hardwired to one SDK and you want to swap/route/fallback models; adding tools/function calling, structured output, or streaming; standing up RAG over Postgres/`pgvector` or an external store; building an eval harness / CI quality gate; adding tracing, cost tracking, caching, or routing/cascades; building or hardening an MCP server.
 
 **Do NOT use when:**

package/skills/design/SKILL.md

@@ -12,6 +12,8 @@ origin: risco
 
 ## When to use / When NOT to use
 
+> **⚠️ SDD new-feature gate — read this first.** If this skill fired on a **new, non-trivial feature or behaviour change** and there is **no approved spec + plan** under `02-DOCS/wiki/sdd/`, STOP — do **not** write feature code yet. Hand off to `../specify/SKILL.md` first: it runs brainstorm → spec → plan → tasks before any code, then routes back here once the plan is approved. Build here directly only for a genuinely one-line / low-risk change. Method: `../sdd/SKILL.md`.
+
 Use when:
 
 - Building a new landing or marketing page.

package/skills/fastapi/SKILL.md

@@ -22,6 +22,8 @@ pip-audit 2.7+, PostgreSQL 16. (All lower bounds; install the latest in each lin
 
 ## When to use
 
+> **⚠️ SDD new-feature gate — read this first.** If this skill fired on a **new, non-trivial feature or behaviour change** and there is **no approved spec + plan** under `02-DOCS/wiki/sdd/`, STOP — do **not** write feature code yet. Hand off to `../specify/SKILL.md` first: it runs brainstorm → spec → plan → tasks before any code, then routes back here once the plan is approved. Build here directly only for a genuinely one-line / low-risk change. Method: `../sdd/SKILL.md`.
+
 - Writing or reviewing any FastAPI route, router, dependency, schema, or app factory.
 - Designing async DB access (SQLAlchemy 2.0), migrations (Alembic), or eager-loading.
 - Adding auth (OAuth2 password flow + JWT), RBAC, password hashing.

package/skills/flutter/SKILL.md

@@ -22,6 +22,8 @@ subproject — never the FastAPI/Go/Next.js siblings.
 
 ## When to use / When NOT to use
 
+> **⚠️ SDD new-feature gate — read this first.** If this skill fired on a **new, non-trivial feature or behaviour change** and there is **no approved spec + plan** under `02-DOCS/wiki/sdd/`, STOP — do **not** write feature code yet. Hand off to `../specify/SKILL.md` first: it runs brainstorm → spec → plan → tasks before any code, then routes back here once the plan is approved. Build here directly only for a genuinely one-line / low-risk change. Method: `../sdd/SKILL.md`.
+
 **Use when:**
 
 - Building a new Flutter feature or screen, or choosing/refactoring state management.

package/skills/go/SKILL.md

@@ -16,6 +16,8 @@ logging, and fixed loop-variable semantics (no more `tt := tt`).
 
 ## When to use / When NOT to use
 
+> **⚠️ SDD new-feature gate — read this first.** If this skill fired on a **new, non-trivial feature or behaviour change** and there is **no approved spec + plan** under `02-DOCS/wiki/sdd/`, STOP — do **not** write feature code yet. Hand off to `../specify/SKILL.md` first: it runs brainstorm → spec → plan → tasks before any code, then routes back here once the plan is approved. Build here directly only for a genuinely one-line / low-risk change. Method: `../sdd/SKILL.md`.
+
 **Use when:**
 
 - Authoring, reviewing, or testing any `.go` file.

package/skills/nextjs/SKILL.md

@@ -13,6 +13,8 @@ origin: risco
 
 ## When to use / When NOT to use
 
+> **⚠️ SDD new-feature gate — read this first.** If this skill fired on a **new, non-trivial feature or behaviour change** and there is **no approved spec + plan** under `02-DOCS/wiki/sdd/`, STOP — do **not** write feature code yet. Hand off to `../specify/SKILL.md` first: it runs brainstorm → spec → plan → tasks before any code, then routes back here once the plan is approved. Build here directly only for a genuinely one-line / low-risk change. Method: `../sdd/SKILL.md`.
+
 **Use when:**
 
 - Editing or creating files under `app/` (pages, layouts, `route.ts`, server actions).

package/skills/postgresdb/SKILL.md

@@ -14,6 +14,8 @@ example is runnable.
 
 ## When to use / When NOT to use
 
+> **⚠️ SDD new-feature gate — read this first.** If this skill fired on a **new, non-trivial feature or behaviour change** and there is **no approved spec + plan** under `02-DOCS/wiki/sdd/`, STOP — do **not** write feature code yet. Hand off to `../specify/SKILL.md` first: it runs brainstorm → spec → plan → tasks before any code, then routes back here once the plan is approved. Build here directly only for a genuinely one-line / low-risk change. Method: `../sdd/SKILL.md`.
+
 **When to use:**
 
 - Schema/DDL decisions: types, keys, constraints, generated/identity columns, enum-vs-lookup, jsonb-vs-column.

package/skills/react/SKILL.md

@@ -12,6 +12,8 @@ origin: risco
 
 ## When to use
 
+> **⚠️ SDD new-feature gate — read this first.** If this skill fired on a **new, non-trivial feature or behaviour change** and there is **no approved spec + plan** under `02-DOCS/wiki/sdd/`, STOP — do **not** write feature code yet. Hand off to `../specify/SKILL.md` first: it runs brainstorm → spec → plan → tasks before any code, then routes back here once the plan is approved. Build here directly only for a genuinely one-line / low-risk change. Method: `../sdd/SKILL.md`.
+
 - A repo with `vite.config.{ts,js}` + `react` + `react-dom` and **no** `next` and **no** `@react-router/dev` framework mode — i.e. an SPA.
 - Creating components and deciding **where state lives** (local / lifted / URL / context / store).
 - Wiring **server data**: queries, mutations, caching, optimistic UI.

package/skills/sdd/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: sdd
-description: "Use when you want a disciplined, spec-driven path from a feature idea to shipped, verified software — the rsc-sdd dispatcher / front door. It states the SDD method, reads the accompaniment dial from 02-DOCS, and routes to the right phase skill: constitution -> specify -> clarify -> plan -> tasks -> analyze -> implement -> verify -> review -> ship, with debug / worktrees / parallel callable on demand. Use it to START a feature, when unsure which SDD phase you are in, or to govern the whole flow. Triggers: 'spec-driven development', 'sdd', 'build this feature properly', 'start a new feature', 'I have an idea, take it to production', 'which phase am I in', 'run the sdd flow', 'desarrollo dirigido por especificación', 'monta esta feature bien', 'de la idea a producción', 'per-phase model routing', 'use a cheaper model for implementation', 'qué modelo por fase'. NOT itself a single phase (it dispatches), NOT the workspace harness (harness), NOT a stack build skill."
+description: "Use when you want a disciplined, spec-driven path from a feature idea to shipped, verified software — the rsc-sdd dispatcher / front door. It states the SDD method, reads the accompaniment dial from 02-DOCS, and routes to the right phase skill: constitution -> specify -> clarify -> plan -> tasks -> analyze -> implement -> verify -> review -> ship, with debug / worktrees / parallel callable on demand. Use it to START a feature, when unsure which SDD phase you are in, or to govern the whole flow. Triggers: 'spec-driven development', 'sdd', 'build this feature properly', 'start a new feature', 'I have an idea, take it to production', 'which phase am I in', 'run the sdd flow', 'desarrollo dirigido por especificación', 'monta esta feature bien', 'munta aquesta feature bé', 'de la idea a producción', 'de la idea a producció', 'fem un SDD per X', 'quina fase soc', 'per-phase model routing', 'use a cheaper model for implementation', 'qué modelo por fase'. NOT itself a single phase (it dispatches), NOT the workspace harness (harness), NOT a stack build skill."
 tags: [sdd, spec, workflow, plan]
 recommends: [sdd-init, constitution, specify]
 profiles: [core, full]

package/skills/specify/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: specify
-description: "Use when a feature, change, or product idea is still fuzzy and needs brainstorming into an APPROVED spec BEFORE any planning or code — the brainstorming front door of SDD. Turns a one-line intent into a WHAT/WHY spec (problem, goals, users, scope, behaviour, acceptance) with zero implementation detail, via one-question-at-a-time dialogue, 2-3 proposed approaches with a recommendation, and a design the user approves before anything gets built. Triggers: 'write a spec for…', 'spec this out', 'brainstorm this feature', 'especifica esta feature', 'I want to add X', 'tengo una idea', 'se me ha ocurrido', '¿y si…?', 'wouldn't it be nice if…', 'let's think this through', 'what should this feature do', 'draft a PRD', or any moment someone jumps to HOW before WHAT is agreed. NOT the technical plan (that's `plan`), NOT the de-risking ambiguity sweep (that's `clarify`), NOT project-wide principles (that's `constitution`)."
+description: "Use when a feature, change, or product idea is still fuzzy and needs brainstorming into an APPROVED spec BEFORE any planning or code — the brainstorming front door of SDD. Turns a one-line intent into a WHAT/WHY spec (problem, goals, users, scope, behaviour, acceptance) with zero implementation detail, via one-question-at-a-time dialogue, 2-3 proposed approaches with a recommendation, and a design the user approves before anything gets built. Triggers: 'write a spec for…', 'spec this out', 'brainstorm this feature', 'especifica esta feature', 'm'agradaria afegir/posar X', 'voldria…', 'vull afegir/fer X', 'es podria afegir…', 'estaria bé que…', 'i si…?', 'I want to add X', 'tengo una idea', 'se me ha ocurrido', '¿y si…?', 'wouldn't it be nice if…', 'let's think this through', 'what should this feature do', 'draft a PRD', or any moment someone jumps to HOW before WHAT is agreed. NOT the technical plan (that's `plan`), NOT the de-risking ambiguity sweep (that's `clarify`), NOT project-wide principles (that's `constitution`)."
 tags: [sdd, spec, requirements]
 recommends: [clarify, plan]
 profiles: [core, full]

package/skills/suggest/SKILL.md

@@ -8,7 +8,44 @@ profiles: [minimal, core, full]
 
 # rsc-suggest — detect & install the skill the task needs
 
-You are always loaded. Your only job: keep the session equipped — nothing else.
+You are always loaded — your body is injected into context at the start of **every** session, and again after every compaction, so you are the one piece guaranteed to be present *before any other skill is matched*. That makes you the **always-on layer**. You do two jobs, in this order:
+
+1. **Route new-feature intent into SDD before any code is written** — the new-feature gate below. This is your first duty; it runs before everything else.
+2. **Keep the session equipped** — detect when the task needs an rsc skill that is **not installed**, name it, and install it on confirm.
+
+---
+
+## The new-feature gate (always-on — runs before any other skill)
+
+This is the **highest-precedence rule in the session.** It fires on **every** user turn, in **any language**, and runs **before you plan, answer, or invoke ANY other skill — no matter how many skills are installed or how strongly one of them matches the request.** That covers the stack skills (`nextjs`, `react`, `fastapi`, `flutter`, `go`, `postgresdb`, `building-agents`, `design`) **and any other skill that would build, create, scaffold, generate, or produce the feature** (e.g. `chatbot`, `course-builder`, `marketing`, automation/connector skills). A skill matching the request does **not** override this gate — it runs *inside* the SDD chain, after the plan is approved. There is no skill with priority over this check.
+
+**The rule (non-negotiable).** The moment the user wants to **build, add, or change a feature**, you MUST route it into SDD via `specify` **first**. **No feature code is written — by ANY skill — until a spec AND a plan exist and the user has approved them.** A stack skill that matched the same request does **not** get to skip this: it builds only *after* the plan is approved.
+
+**Where does this turn go? When unsure, choose `specify` — the safe default.**
+
+| The turn is… | Route to |
+| --- | --- |
+| A new feature / capability / integration / UI, a behaviour change, a data-model or architecture change, "it should also…", anything non-trivial | **`specify`** → `clarify` → `plan` → `tasks` → `implement` (which fans work out to subagents via `parallel`) |
+| A genuinely one-line / low-risk change: typo, copy tweak, config bump, rename, non-breaking dependency bump | Just do it inline, then verify — and **say out loud** you are skipping the chain |
+| A bug fix that restores intended behaviour | **`debug`**, then resume |
+| Ambiguous / in-between / you cannot tell | **`specify`** — a skipped spec is where drift hides |
+
+**Triggers — detect the *intent*, never a fixed phrase, in ANY language.** What fires the gate is the **meaning**, not the words: the user wants something to exist or behave differently than it does now — build, add, create, change, replace, integrate, "it should also…", "wouldn't it be nice if…". This is judged **semantically**, so it holds in **any language** — Catalan, Spanish, English, Portuguese, French, Italian, German, Basque, Galician, or anything else, including a language with no example below. The lists that follow are **illustrative examples, NOT a checklist**: never wait for one of these phrases to appear before firing. If the meaning is feature-shaped, the gate fires — full stop.
+- **CA:** "m'agradaria afegir/posar…", "vull fer/posar…", "es podria…", "i si…".
+- **ES:** "quiero añadir/montar…", "me gustaría…", "se me ha ocurrido", "¿y si…?".
+- **EN:** "I want to add…", "let's build…", "it should also…".
+- A **URL plus a description of desired behaviour** ("on this page I'd like…") **is** a feature request — in any language.
+
+**Stop rationalizing — every one of these is wrong:**
+- *"I understand the feature, I'll just build it."* → That is the exact failure SDD prevents. Spec first; the artifact is the contract.
+- *"A more specific skill matched (a stack skill, `chatbot`, `course-builder`, marketing…), so it takes precedence."* → **No skill outranks this gate.** Any builder skill **defers** to `specify` for new features and runs *inside* the chain, after the plan is approved. Route first.
+- *"The user gave lots of detail / a URL, so they want code now."* → Detail feeds the spec, not the editor.
+- *"The dial is L0, so I'll skip the gate to stay terse."* → L0 changes how many words and questions, **never** whether the gate fires.
+- *"It's phrased in a language I have no example for, so maybe it isn't a feature request."* → The trigger lists are examples, not a closed set. Judge the **meaning**, not the keywords; any language with build/add/change intent fires the gate identically.
+
+If `specify` / `sdd` are **not installed**, fall through to the install detector below and offer to add them *before* routing. The gate decides **where the turn goes**; the detector below only handles **missing** skills. Full method and phase map: `../sdd/SKILL.md`.
+
+---
 
 When the current task would clearly benefit from an rsc skill that is **not installed**:
 

package/targets/claude.js

@@ -107,7 +107,24 @@ export function wireHook(paths) {
   );
   settings.hooks.PreToolUse.push({ matcher: 'Bash', hooks: [{ type: 'command', command: dgCmd }] });
 
+  // New-feature gate: a UserPromptSubmit hook that re-injects the SDD new-feature gate as
+  // the most-recent instruction on every user turn. SessionStart injects the full gate (the
+  // `suggest` body) once; this keeps the precedence rule salient regardless of how many
+  // skills are installed or how long the session runs (otherwise a strongly-matched stack
+  // skill can pull the model to code despite the gate being in context). UserPromptSubmit
+  // stdout is added to context, so a plain print suffices. Materialized + node-run
+  // (Windows-safe), idempotent, fail-open, opt-out via .rsc/.no-feature-gate. Other
+  // (non-rsc) UserPromptSubmit hooks are preserved.
+  const fgDest = join(paths.projectRoot, '.rsc', 'userprompt-gate.mjs');
+  copyFileSync(join(HERE, 'userprompt-gate.mjs'), fgDest);
+  const fgCmd = `node "${fgDest}" "${paths.projectRoot}"`;
+  settings.hooks.UserPromptSubmit ||= [];
+  settings.hooks.UserPromptSubmit = settings.hooks.UserPromptSubmit.filter(
+    (e) => !JSON.stringify(e).includes('.rsc/userprompt-gate.'),
+  );
+  settings.hooks.UserPromptSubmit.push({ hooks: [{ type: 'command', command: fgCmd }] });
+
   mkdirSync(dirname(file), { recursive: true });
   writeFileSync(file, JSON.stringify(settings, null, 2) + '\n');
-  return [file, scriptDest, wlDest, sgDest, dgDest];
+  return [file, scriptDest, wlDest, sgDest, dgDest, fgDest];
 }

package/targets/userprompt-gate.mjs

@@ -0,0 +1,34 @@
+#!/usr/bin/env node
+// rsc UserPromptSubmit payload (claude). Re-injects the SDD new-feature gate as the
+// MOST-RECENT instruction on every user turn. The SessionStart hook already injects the
+// full gate (the `suggest` body) once per session, but in a long session — or one with
+// many installed skills whose descriptions crowd the context — that single injection can
+// lose salience and a strongly-matched stack/builder skill can pull the model straight to
+// code. This keeps the precedence rule in front of the model every turn, so the gate is
+// independent of skill count and session length. Stdout is added to context for
+// UserPromptSubmit, so a plain print is enough (no JSON needed).
+//
+// Invoked as `node userprompt-gate.mjs <projectRoot>` (not bash) so it runs on Windows too.
+//   argv[2] = absolute project root
+// Fail-open (never blocks a turn). Opt out per project with .rsc/.no-feature-gate.
+import { existsSync } from 'node:fs';
+import { join } from 'node:path';
+
+const root = process.argv[2] || process.cwd();
+
+// Opt-out: a project that does not want the always-on gate drops this marker file.
+if (existsSync(join(root, '.rsc', '.no-feature-gate'))) process.exit(0);
+
+process.stdout.write(`===== rsc SDD new-feature gate (highest precedence) =====
+Before acting on this turn: if the user wants to BUILD, ADD, or CHANGE a feature — in
+ANY language, judged by intent, not by keywords — you MUST route it through SDD via
+\`specify\` FIRST. No feature code is written by ANY skill (stack skills included —
+nextjs/react/fastapi/flutter/go/postgresdb/building-agents/design — and any builder skill
+such as chatbot/course-builder/marketing) until a spec AND a plan exist and the user has
+approved them. No skill outranks this gate.
+- Unclear / in-between? -> \`specify\` (the safe default; a skipped spec is where drift hides).
+- One-line / low-risk change, or a bug fix restoring intended behaviour? -> skip the chain,
+  do it, and say so out loud.
+Full gate + decision table live in the always-on \`suggest\` body; method in \`sdd\`.
+=========================================================
+`);