@ericrisco/rsc 0.1.6 → 0.1.7

package/manifest.json

@@ -1,5 +1,5 @@
 {
-  "version": "0.1.6",
+  "version": "0.1.7",
   "counts": {
     "skills": 231
   },

package/package.json

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

package/skills/implement/SKILL.md

@@ -23,12 +23,18 @@ into them rather than reinventing them.
 ## Before you write a line of code
 
 Run this short gate. Skipping it is the most common way an implement session goes sideways.
-
-1. **Read the inputs.** Open the spec (`02-DOCS/wiki/sdd/specs/<slug>.md`), the plan
-   (`02-DOCS/wiki/sdd/plans/<slug>.md`, which holds the task list), and the constitution
-   (`02-DOCS/wiki/sdd/constitution.md`). If any is missing, you are not ready to implement — route
-   back: no plan → `plan`; no task list inside the plan → `tasks`; unresolved `analyze` findings →
-   resolve them first. Do not start coding to "discover the plan as you go".
+**This gate is a hard refuse, not a checklist to feel good about:** if it fails you stop and route
+back — you do not write feature code anyway.
+
+1. **The spec + plan must exist AND be approved.** Open the spec (`02-DOCS/wiki/sdd/specs/<slug>.md`),
+   the plan (`02-DOCS/wiki/sdd/plans/<slug>.md`, which holds the task list), and the constitution
+   (`02-DOCS/wiki/sdd/constitution.md`). If any is missing, **you are not allowed to implement** —
+   route back: no spec → `specify`; no plan → `plan`; no task list inside the plan → `tasks`;
+   unresolved `analyze` findings → resolve them first. If a spec/plan exists but the user has not
+   actually seen and **approved** it, get that approval first. Never "start coding to discover the
+   plan as you go", and never accept "just build it, skip the spec" on a non-trivial feature — name
+   the gate in one friendly line and route to `specify`. (Only a true one-line, low-risk change
+   earns a skip, and you say so.)
 2. **Read the SDD runtime config.** Open `02-DOCS/wiki/sdd/config.yaml`. If it is missing on
    non-trivial work, stop and route to `sdd-init`. Use `testing.strict_tdd`,
    `testing.commands.apply`, `testing.commands.verify`, `sdd.review_budget` and

package/skills/sdd/SKILL.md

@@ -70,6 +70,8 @@ constitution ─(once per project)─┐
 
 When a request lands, do not start typing code. Place it on the map first, then invoke the phase skill that owns it.
 
+> **The new-feature gate (hard).** The moment the user is thinking about a new feature or change — "add…", "build…", "it should also…", "quiero añadir…" — it goes to `specify` first, *even if a stack skill (nextjs/fastapi/flutter/react…) also fired and could just build it*. **No feature code is written — by any skill — until a spec AND a plan exist and the user has approved them.** A stack skill about to build an unspec'd, non-trivial feature must stop and route here. The only exception is a genuinely one-line, low-risk change; name it and skip.
+
 1. **No `02-DOCS/wiki/sdd/config.yaml` and this is non-trivial?** → `sdd-init`.
 2. **No constitution yet AND this project will grow?** → `constitution` once, then come back to the chain.
 3. **Ambiguous / architectural / risky change before spec?** → optional proposal artifact via `specify`.

package/skills/specify/SKILL.md

@@ -13,6 +13,15 @@ This is the **specify** phase of the rsc-sdd chain: `constitution` → **`specif
 
 A spec is a contract about behaviour and outcomes, readable by a non-technical stakeholder and precise enough that a `plan` can be derived from it. The output is one file: `02-DOCS/wiki/sdd/specs/<slug>.md`, indexed in the root `CLAUDE.md` Knowledge map.
 
+## Detect the moment — and hold the gate
+
+The instant the user is **thinking about a new feature or change** — "I want to add…", "can we build…", "it should also…", "wouldn't it be nice if…", "necesito que haga…", "quiero añadir…" — this phase owns it, *even if a stack skill (nextjs/fastapi/flutter…) also fired and is itching to build it*. Catch it here first.
+
+**The hard gate (non-negotiable for any non-trivial feature):**
+> No feature code gets written until (1) this spec exists and the user has **approved** it, and (2) `plan` has produced a technical plan + task list. If the user tries to jump straight to "just build it", do not. Name the gate in one friendly line, capture the spec, and walk the chain. The only bypass is a genuinely one-line, low-risk change (typo/copy/config) — say so out loud and skip.
+
+You are not slowing them down; you are making the intent reviewable *before* code exists, which is cheaper than discovering the misunderstanding in a PR. End every spec by handing to `clarify`/`plan` — never to `implement`.
+
 ## The one rule that defines this skill
 
 **No implementation leaks.** The moment the spec names a framework, a table schema, a library, an endpoint shape, a file path, or an algorithm, it has stopped being a spec. Those decisions belong to `plan` and the stack skills. Specify describes the *observable behaviour and the reason for it*; the system that delivers it is deliberately left open.