@ericrisco/rsc 0.1.8 → 0.1.9

package/manifest.json

@@ -1,5 +1,5 @@
 {
-  "version": "0.1.8",
+  "version": "0.1.9",
   "counts": {
     "skills": 231
   },
@@ -3971,7 +3971,7 @@
     },
     {
       "id": "specify",
-      "description": "Use when a feature, change, or product idea is still fuzzy and needs to become a written spec BEFORE any planning or code — turn a one-line intent into a WHAT/WHY specification (problem, goals, users, scope, behaviour, acceptance criteria) with zero implementation detail. Triggers: 'write a spec for…', 'spec this out', 'especifica esta feature', 'I want to add X but haven't thought it through', 'capture requirements for…', 'what should this feature do', 'draft a PRD', 'define the feature before we build', kicking off an SDD feature after the constitution exists, or any moment someone jumps to HOW before WHAT is agreed. Asks ONE focused question at a time only where it cannot infer, then writes 02-DOCS/wiki/sdd/specs/<slug>.md and marks open points to clarify. 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', '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.8",
+  "version": "0.1.9",
   "description": "Eric Risco's agent-skills catalog as a granular, self-recommending CLI installer.",
   "type": "module",
   "bin": {

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 to become a written spec BEFORE any planning or code — turn a one-line intent into a WHAT/WHY specification (problem, goals, users, scope, behaviour, acceptance criteria) with zero implementation detail. Triggers: 'write a spec for…', 'spec this out', 'especifica esta feature', 'I want to add X but haven't thought it through', 'capture requirements for…', 'what should this feature do', 'draft a PRD', 'define the feature before we build', kicking off an SDD feature after the constitution exists, or any moment someone jumps to HOW before WHAT is agreed. Asks ONE focused question at a time only where it cannot infer, then writes 02-DOCS/wiki/sdd/specs/<slug>.md and marks open points to clarify. 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', '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]
@@ -15,12 +15,12 @@ A spec is a contract about behaviour and outcomes, readable by a non-technical s
 
 ## 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.
+Fire on the **faintest** sign the user is thinking about a new feature or change — not just "spec this", but any musing: "I want to add…", "can we build…", "it should also…", "wouldn't it be nice if…", "what if we…", "I've been thinking about…", "let's brainstorm…", "tengo una idea", "se me ha ocurrido", "¿y si…?", "estaría guapo que…", "quiero añadir…", "necesito que haga…". This phase owns that moment, *even if a stack skill (nextjs/fastapi/flutter…) also fired and is itching to build it*. Catch it here first — being too eager to brainstorm is cheap; skipping it is expensive.
 
-**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.
+**The hard gate — every feature, including the "obvious" ones:**
+> No implementation starts — not a stack skill, not `plan`-to-code, not "just a quick version" — until the user has **approved a design** (the spec at step 9 below) and `plan` has produced the technical plan + task list. If the user says "just build it", do not; name the gate in one friendly line and run the loop. "Too simple to need a design" is the rationalization that wastes the most work — every feature gets the loop. The only thing that skips it is a literal one-line, zero-risk change (typo/copy/config) — say so out loud and do it.
 
-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`.
+You are not slowing them down; you make the intent reviewable *before* code exists, which is far 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
 
@@ -78,16 +78,24 @@ A criterion that needs a human to "decide if it's good enough" is not done yet
 
 ## The pass, end to end
 
+Run these in order. It is a collaborative dialogue, not a form you fill in silence — and **you do not skip to a design dump.** Track the steps with a todo list so none is dropped.
+
 ```text
-1. READ profile + sdd config + constitution + existing specs → set verbosity, inherit principles, avoid dupes
-2. IF risky/architectural, DRAFT proposal first              → alternatives, tradeoffs, risks, rollback
-3. RESTATE the intent in one sentence                        → confirm you understood before drafting
-4. INFER every section you can                               → from constitution, wiki, the intent itself
-5. ASK the gaps that change scope, one at a time             → record each answer, then ask the next
-6. DRAFT 02-DOCS/wiki/sdd/specs/<slug>.md                     → WHAT/WHY only, template sections filled
-7. LIST Points to clarify                                    → open questions + assumptions, the clarify handoff
-8. INDEX it in root CLAUDE.md Knowledge map                   → under the sdd/specs topic
-9. END with result envelope and HAND OFF to clarify           → name the next phase explicitly
+1. EXPLORE context        → profile + sdd config + constitution + existing specs + wiki + recent git
+2. SCOPE check            → if the request is several independent subsystems, DECOMPOSE into sub-specs first,
+                            then brainstorm the FIRST one; each gets its own spec → plan → build cycle
+3. RESTATE in one sentence→ confirm you understood the intent before anything else
+4. ASK, one at a time     → only the gaps that change scope; multiple-choice when you can; wait, record, repeat
+5. PROPOSE 2-3 approaches → distinct directions with honest trade-offs; lead with your recommendation and why
+6. PRESENT the design     → section by section (problem, users, behaviour, acceptance), scaled to complexity;
+                            after EACH section ask "does this look right?" and adjust before moving on
+7. WRITE the spec         → 02-DOCS/wiki/sdd/specs/<slug>.md (WHAT/WHY), index it in CLAUDE.md, commit if a repo
+8. SELF-REVIEW            → scan for TODO/placeholder, contradictions, ambiguity, scope creep; fix inline
+9. USER APPROVES          → ask them to read the written spec and confirm; loop on changes until they approve
+10. HAND OFF              → only now, result envelope → clarify/plan. NEVER to implement.
+```
+
+**The gate is steps 5-9, and it is the point of this skill.** Implementation does not begin — not `plan`-to-code, not a stack skill, not "just a quick version" — until the user has approved the design at step 9. This holds for **every** feature, including ones that feel too small to design; "too simple to spec" is exactly where unexamined assumptions cost the most. The only thing that skips the loop is a literal one-line, zero-risk change (a typo, a copy tweak) — name it as such and do it.
 ```
 
 `<slug>` is a short kebab-case name derived from the feature (e.g. `bulk-csv-import`, `magic-link-login`). If a spec with that slug exists, read it and update rather than overwrite.
@@ -165,6 +173,9 @@ The proposal is allowed to mention options and tradeoffs; the spec that follows
 | Dump 12 questions in one message | One focused question per turn. Infer the rest from the constitution and wiki. |
 | Ask a question you could answer from the constitution | Read it first. Only ask what genuinely changes the spec. |
 | Write "it should work well / be fast / be intuitive" | Not testable. Make it a binary Given/When/Then or move it to Points to clarify. |
+| Skip the whole loop because "this is too simple to design" | That's the rationalization that wastes the most work. Every feature gets the loop; only a literal one-line, zero-risk change skips. |
+| Present one approach as the answer | Offer 2-3 distinct directions with trade-offs and a recommendation; let the user choose before you write the spec. |
+| Hand to `plan`/`implement` before the user approved the written spec | The approval at step 9 is the gate. No design approved → nothing gets built. |
 | Skip non-goals because "it's obvious" | Unsaid scope becomes assumed scope. State what you are *not* doing. |
 | Resolve every ambiguity yourself to look finished | Inventing answers is worse than naming gaps. List them in Points to clarify. |
 | Start designing the solution because it's clearer | Stay on WHAT/WHY. The plan is a later, separate phase. |