@ericrisco/rsc 0.1.7 → 0.1.9

package/manifest.json

@@ -1,5 +1,5 @@
 {
-  "version": "0.1.7",
+  "version": "0.1.9",
   "counts": {
     "skills": 231
   },
@@ -279,7 +279,7 @@
     },
     {
       "id": "author-skill",
-      "description": "Use when authoring a NEW skill or editing an existing one for the rsc catalog — writing or fixing a SKILL.md, crafting a trigger-rich third-person description that fires on the right prompts, deciding what goes in references/ vs the body, writing evals/cases.yaml + evals/README.md, or wiring a skill into the catalog (tags, recommends, manifest). Triggers: 'write a skill', 'author a skill', 'create a new skill', 'escribe una skill', 'haz una skill nueva', 'edit this skill', 'improve this skill', 'my skill never triggers', 'my skill always fires', 'fix the description', 'the frontmatter is invalid', 'write evals for this skill', 'add this skill to the catalog', 'audit this skill against the rubric', 'progressive disclosure', 'SKILL.md too long'. Knows the rsc conventions: hybrid layout, tags/recommends frontmatter, manifest.json, the npx rsc CLI, the Knowledge map. NOT building runtime features (that is the SDD chain) and NOT general docs.",
+      "description": "Use when authoring a NEW skill or editing an existing one for the rsc catalog — writing or fixing a SKILL.md, crafting a trigger-rich third-person description that fires on the right prompts, deciding what goes in references/ vs the body, writing evals/cases.yaml + evals/README.md, or wiring a skill into the catalog (tags, recommends, manifest). Triggers: 'write a skill', 'author a skill', 'create a new skill', 'escribe una skill', 'haz una skill nueva', 'edit this skill', 'improve this skill', 'my skill never triggers', 'my skill always fires', 'fix the description', 'the frontmatter is invalid', 'write evals for this skill', 'add this skill to the catalog', 'audit this skill against the rubric', 'progressive disclosure', 'SKILL.md too long'. Knows the rsc conventions: hybrid layout, tags/recommends frontmatter, manifest.json, the npx @ericrisco/rsc CLI, the Knowledge map. NOT building runtime features (that is the SDD chain) and NOT general docs.",
       "tags": [
         "skill",
         "authoring",
@@ -2017,7 +2017,7 @@
     },
     {
       "id": "init",
-      "description": "Use when starting from nothing or pointing the rsc-skills harness at an existing project — the front door / bootstrapper. It gauges the user's technical level FIRST (non-technical by default), sets an explanation/accompaniment dial, then discovers what they want to build OR govern (any software stack, OR a non-code harness: running a company/ops, research, personal knowledge, content). It detects greenfield vs brownfield, profiles the user into 02-DOCS, RECOMMENDS which rsc skills to install (printing the exact `npx rsc add` commands), and hands off to the harness skill to scaffold 01-TOOLS + 02-DOCS. Triggers: 'empezar de cero', 'no sé por dónde empezar', 'start a new project', 'bootstrap', 'set up the harness', 'monta el proyecto', 'quiero montar una empresa/ops/wiki con esto', 'arranca', 'init'. NOT the scaffolder itself (that's the harness skill) and NOT a specific stack skill.",
+      "description": "Use when starting from nothing or pointing the rsc-skills harness at an existing project — the front door / bootstrapper. It gauges the user's technical level FIRST (non-technical by default), sets an explanation/accompaniment dial, then discovers what they want to build OR govern (any software stack, OR a non-code harness: running a company/ops, research, personal knowledge, content). It detects greenfield vs brownfield, profiles the user into 02-DOCS, RECOMMENDS which rsc skills to install (printing the exact `npx @ericrisco/rsc add` commands), and hands off to the harness skill to scaffold 01-TOOLS + 02-DOCS. Triggers: 'empezar de cero', 'no sé por dónde empezar', 'start a new project', 'bootstrap', 'set up the harness', 'monta el proyecto', 'quiero montar una empresa/ops/wiki con esto', 'arranca', 'init'. NOT the scaffolder itself (that's the harness skill) and NOT a specific stack skill.",
       "tags": [
         "init",
         "bootstrap",
@@ -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",
@@ -4112,7 +4112,7 @@
     },
     {
       "id": "suggest",
-      "description": "Always-on. Use whenever the current task would clearly benefit from an rsc skill that is not yet installed — detect the gap, name the skill, and (with a one-word confirm) install it via `npx rsc add <id>`. Triggers on any task that maps to a known rsc capability the session lacks: building a web/app/API, a database, security, deployment, agents, content, or connecting/documenting a company.",
+      "description": "Always-on. Use whenever the current task would clearly benefit from an rsc skill that is not yet installed — detect the gap, name the skill, and (with a one-word confirm) install it via `npx @ericrisco/rsc add <id>`. Triggers on any task that maps to a known rsc capability the session lacks: building a web/app/API, a database, security, deployment, agents, content, or connecting/documenting a company.",
       "tags": [
         "suggest",
         "detect",

package/package.json

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

package/skills/author-skill/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: author-skill
-description: "Use when authoring a NEW skill or editing an existing one for the rsc catalog — writing or fixing a SKILL.md, crafting a trigger-rich third-person description that fires on the right prompts, deciding what goes in references/ vs the body, writing evals/cases.yaml + evals/README.md, or wiring a skill into the catalog (tags, recommends, manifest). Triggers: 'write a skill', 'author a skill', 'create a new skill', 'escribe una skill', 'haz una skill nueva', 'edit this skill', 'improve this skill', 'my skill never triggers', 'my skill always fires', 'fix the description', 'the frontmatter is invalid', 'write evals for this skill', 'add this skill to the catalog', 'audit this skill against the rubric', 'progressive disclosure', 'SKILL.md too long'. Knows the rsc conventions: hybrid layout, tags/recommends frontmatter, manifest.json, the npx rsc CLI, the Knowledge map. NOT building runtime features (that is the SDD chain) and NOT general docs."
+description: "Use when authoring a NEW skill or editing an existing one for the rsc catalog — writing or fixing a SKILL.md, crafting a trigger-rich third-person description that fires on the right prompts, deciding what goes in references/ vs the body, writing evals/cases.yaml + evals/README.md, or wiring a skill into the catalog (tags, recommends, manifest). Triggers: 'write a skill', 'author a skill', 'create a new skill', 'escribe una skill', 'haz una skill nueva', 'edit this skill', 'improve this skill', 'my skill never triggers', 'my skill always fires', 'fix the description', 'the frontmatter is invalid', 'write evals for this skill', 'add this skill to the catalog', 'audit this skill against the rubric', 'progressive disclosure', 'SKILL.md too long'. Knows the rsc conventions: hybrid layout, tags/recommends frontmatter, manifest.json, the npx @ericrisco/rsc CLI, the Knowledge map. NOT building runtime features (that is the SDD chain) and NOT general docs."
 tags: [skill, authoring, meta]
 recommends: []
 origin: risco

package/skills/author-skill/references/rsc-conventions.md

@@ -2,7 +2,7 @@
 
 A skill is not done when `SKILL.md` reads well. It is done when it is *in the
 catalog* — frontmatter valid, indexed in the manifest, discoverable by the
-`npx rsc` recommender, and reachable where the agent will find it. This reference
+`npx @ericrisco/rsc` recommender, and reachable where the agent will find it. This reference
 is the rsc plumbing.
 
 ## The layout (single source of truth)
@@ -52,7 +52,7 @@ profiles: [core, full]           # optional: named-profile membership
 There are no bundles and no `/<bundle>:<id>` namespacing. A skill installs under
 the target's rsc namespace (e.g. `~/.claude/skills/rsc/<id>/`) and is invoked by
 its `name`. The `suggest` detector is always installed (the floor) and proposes
-installing any skill a task needs via `npx rsc add <id>`.
+installing any skill a task needs via `npx @ericrisco/rsc add <id>`.
 
 ## Wiring steps for a new skill
 

package/skills/harness/SKILL.md

@@ -259,6 +259,18 @@ Print a final report:
   - `01-TOOLS/<X>/test_connection.{sh,py}` once `.env` is filled.
   - Any subproject with a dirty git tree to clean up.
 
+## Equip — install the skills this workspace needs
+
+Once the structure stands, make sure the workspace has the rsc skills its stack and goals call for — detection here, not just at `init`:
+
+1. **Detect → propose.** From the detected stacks/providers and the user's goals in `02-DOCS/wiki/harness/`, build a shortlist. Ask the CLI if unsure: `npx @ericrisco/rsc consult "<stack + goal>"`. (Map e.g. detected Stripe→`stripe`, Postgres→`postgresdb`, Next→`nextjs`+`design`, a company/ops focus→`finance-ops`/`invoicing`/`gdpr-privacy`…)
+2. **Confirm, then install yourself.** Show the shortlist with a one-line *why* each (matched to the dial), get a one-word confirm, and run it via Bash — installing writes to their environment, so always confirm first:
+   ```bash
+   npx @ericrisco/rsc add <skill> [<skill> ...]
+   ```
+   Can't run a shell? Print the exact command for another terminal tab.
+3. **Flag the new session.** New skills load at session start — tell the user to open a **new tab/session** (or reload Cursor/Codex/Gemini) in this folder for them to activate. Log the installed set in `02-DOCS/wiki/harness/decisions.md`.
+
 ## Iron rules (non-negotiable)
 
 These rules cut across every phase. Violating any one of them aborts the run.

package/skills/implement/SKILL.md

@@ -41,7 +41,7 @@ back — you do not write feature code anyway.
    `sdd.registry_path`. Do not choose a different test command from memory while config exists.
 3. **Read the skill registry.** Open `.rsc/skill-registry.json` if present. Select only the
    relevant stack/process skills for this task, then digest them into compact rules. If the
-   registry is missing, run or recommend `npx rsc registry refresh` and record the fallback.
+   registry is missing, run or recommend `npx @ericrisco/rsc registry refresh` and record the fallback.
 4. **Read the accompaniment dial.** Open `02-DOCS/wiki/harness/user-profile.md` and read the
    technical + accompaniment level. It sets how loud you are at each checkpoint (see the dial table
    below). No profile yet → assume non-technical, narrate more, and ask before any irreversible step.

package/skills/init/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: init
-description: "Use when starting from nothing or pointing the rsc-skills harness at an existing project — the front door / bootstrapper. It gauges the user's technical level FIRST (non-technical by default), sets an explanation/accompaniment dial, then discovers what they want to build OR govern (any software stack, OR a non-code harness: running a company/ops, research, personal knowledge, content). It detects greenfield vs brownfield, profiles the user into 02-DOCS, RECOMMENDS which rsc skills to install (printing the exact `npx rsc add` commands), and hands off to the harness skill to scaffold 01-TOOLS + 02-DOCS. Triggers: 'empezar de cero', 'no sé por dónde empezar', 'start a new project', 'bootstrap', 'set up the harness', 'monta el proyecto', 'quiero montar una empresa/ops/wiki con esto', 'arranca', 'init'. NOT the scaffolder itself (that's the harness skill) and NOT a specific stack skill."
+description: "Use when starting from nothing or pointing the rsc-skills harness at an existing project — the front door / bootstrapper. It gauges the user's technical level FIRST (non-technical by default), sets an explanation/accompaniment dial, then discovers what they want to build OR govern (any software stack, OR a non-code harness: running a company/ops, research, personal knowledge, content). It detects greenfield vs brownfield, profiles the user into 02-DOCS, RECOMMENDS which rsc skills to install (printing the exact `npx @ericrisco/rsc add` commands), and hands off to the harness skill to scaffold 01-TOOLS + 02-DOCS. Triggers: 'empezar de cero', 'no sé por dónde empezar', 'start a new project', 'bootstrap', 'set up the harness', 'monta el proyecto', 'quiero montar una empresa/ops/wiki con esto', 'arranca', 'init'. NOT the scaffolder itself (that's the harness skill) and NOT a specific stack skill."
 tags: [init, bootstrap, start, new, setup]
 recommends: [harness]
 profiles: [minimal, core, full]
@@ -110,9 +110,9 @@ Figure out two things: **the state of the ground** and **what they want**.
 
 Record everything to `02-DOCS/wiki/harness/` as you go. Use the greenfield and brownfield questionnaires (for software AND non-code harnesses) in `references/discovery.md`. Ask in batches sized to the accompaniment level — never dump every question at once.
 
-### Phase 3 — RECOMMEND
+### Phase 3 — DETECT & INSTALL
 
-Map what you learned to individual rsc skills and **print the exact `npx rsc add` commands**. A skill cannot install anything itself — it recommends and prints commands the user runs. Skill map:
+Map what you learned to individual rsc skills. **You have a terminal — install them yourself.** After a one-word confirm, run `npx @ericrisco/rsc add <ids>` via Bash. (If you genuinely cannot run a shell, print the exact command and tell the user to paste it in another terminal tab.) Then tell them the **new skills activate in a fresh session/tab** — see the install note below the table. Skill map:
 
 | Need | Skills | Why (one line, matched to level) |
 | --- | --- | --- |
@@ -123,19 +123,21 @@ Map what you learned to individual rsc skills and **print the exact `npx rsc add
 | AI agents | `building-agents` | Agent loops, tools, RAG. |
 | Security & shipping / ops (incl. non-code company harness connecting tools) | `secure-coding`, `deployment` | Ship it safely and wire up external tools. |
 
-Print, with a one-line *why* per recommended skill (language matched to the user's level):
+Show the shortlist with a one-line *why* per skill (language matched to the user's level), get a one-word confirm, then install:
 
 ```text
-npx rsc add <skill> [<skill> ...]
+npx @ericrisco/rsc add <skill> [<skill> ...]
 ```
 
-Recommend only skills their answers justify — same discipline as "no speculative tools". Full skill map, sample printouts per scenario, and the requirements-first decision pattern → `references/recommend-skills.md`.
+> **After installing, say this (matched to their IDE):** "Listo, instaladas. Para que se activen, abre una **pestaña/sesión nueva** de Claude Code (o recarga Cursor/Codex/Gemini) en esta carpeta — las skills se cargan al arrancar la sesión." If you couldn't run the command yourself, give it to them to run in another terminal tab, then the same new-session note.
+
+Install only skills their answers justify — same discipline as "no speculative tools". Full skill map, sample printouts per scenario, and the requirements-first decision pattern → `references/recommend-skills.md`.
 
 ### Phase 4 — HANDOFF
 
-Tell the user to install `harness` (`npx rsc add harness`) and then run the **`harness`** skill to actually scaffold the `01-TOOLS/` + `02-DOCS/` workspace. `init` stops here — it has set the profile, recorded the discovery, and recommended the skills. `harness` reads the profile and builds the structure.
+Tell the user to install `harness` (`npx @ericrisco/rsc add harness`) and then run the **`harness`** skill to actually scaffold the `01-TOOLS/` + `02-DOCS/` workspace. `init` stops here — it has set the profile, recorded the discovery, and recommended the skills. `harness` reads the profile and builds the structure.
 
-> "Tu perfil y lo que hemos hablado ya están guardados. Cuando hayas instalado las skills de arriba (`npx rsc add …`), ejecuta `harness` y monto el esqueleto del proyecto (`01-TOOLS/` + `02-DOCS/`) leyendo todo lo que acabamos de decidir."
+> "Tu perfil y lo que hemos hablado ya están guardados. Cuando hayas instalado las skills de arriba (`npx @ericrisco/rsc add …`), ejecuta `harness` y monto el esqueleto del proyecto (`01-TOOLS/` + `02-DOCS/`) leyendo todo lo que acabamos de decidir."
 
 ## Iron rules (non-negotiable)
 
@@ -143,7 +145,7 @@ Tell the user to install `harness` (`npx rsc add harness`) and then run the **`h
 2. **Non-technical by default.** Plain language until told otherwise. Never assume the user reads code.
 3. **The dial governs verbosity AND question count.** Read it, obey it, in this skill and every skill downstream. L0 means *do it and stop talking*; L3 means *explain everything and ask*.
 4. **Three options, requirements first.** For any significant decision: gather the driving requirements, present exactly 3 options with honest trade-offs, recommend one, log it.
-5. **Recommend, never install.** A skill cannot run `npx rsc add`. Print the commands; the user runs them.
+5. **Install with consent, then flag the new session.** You have a terminal: after a one-word confirm, run `npx @ericrisco/rsc add …` yourself. Newly installed skills load at the START of a session, so tell the user to open a **new tab/session** (or reload) for them to activate. If you cannot run a shell, hand them the exact command for another tab — never install without a confirm.
 6. **No speculative skills.** Recommend a skill only if the discovery justified it. No "you'll probably want agents too".
 7. **Persist as you learn.** Goals, context, constraints, decisions go to `02-DOCS/wiki/harness/` continuously — `user-profile.md` for state, `decisions.md` append-only for choices.
 8. **`init` writes only the profile + the link.** It writes ONLY the user-profile + decisions log under `02-DOCS/wiki/harness/` and the `CLAUDE.md` Knowledge-map link. ALL other `01-TOOLS/` + `02-DOCS/` scaffolding is the `harness` skill's job. Hand off; do not do its job.
@@ -162,7 +164,7 @@ These thoughts mean the skill is about to break its own rules. Recognize and abo
 | "I'll scaffold 01-TOOLS now while I'm here" | No. That's the `harness` skill. `init` profiles and hands off. |
 | "The profile can wait until after discovery" | No. Profile first — every later question's framing depends on it. |
 | "This is a company, not code, so the harness doesn't apply" | No. Domain-agnostic. A non-code harness uses the same structure. |
-| "I'll install the skills for them" | No. A skill can't install. Print the `npx rsc add` commands. |
+| "I'll install the skills for them" | No. A skill can't install. Print the `npx @ericrisco/rsc add` commands. |
 | "They said 'ok', that's enough to pick the database" | No. A significant decision needs the 3-option pattern and a log entry. |
 
 ## Project grounding (02-DOCS + CLAUDE.md)

package/skills/init/evals/cases.yaml

@@ -60,7 +60,7 @@ capability:
       - "Presents the accompaniment dial L0–L3 and, given a silent non-technical user, defaults to L3 (full accompaniment)"
       - "Persists the profile to 02-DOCS/wiki/harness/user-profile.md and an append-only 02-DOCS/wiki/harness/decisions.md, and links both from a ## Knowledge map section in root CLAUDE.md (creating CLAUDE.md if absent, additive only)"
       - "Detects greenfield vs brownfield rather than assuming, and runs DISCOVER (goals, audience, constraints, surfaces) before recommending"
-      - "Recommends specific rsc skills matched to discovery (at minimum harness; nextjs/flutter + design if app surfaces justify it) and PRINTS the exact install commands (npx rsc add <skill> ...)"
+      - "Recommends specific rsc skills matched to discovery (at minimum harness; nextjs/flutter + design if app surfaces justify it) and PRINTS the exact install commands (npx @ericrisco/rsc add <skill> ...)"
       - "Does NOT install anything itself and does NOT scaffold 01-TOOLS/02-DOCS — it hands off to the harness skill as the final step"
       - "Does not recommend speculative skills (e.g. building-agents) unless discovery justified them"
 

package/skills/init/references/recommend-skills.md

@@ -1,7 +1,7 @@
 # Recommend Skills — the skill map, sample printouts & the "siempre 3 opciones" pattern
 
 Phase 3 detail. Map discovery to individual rsc skills, print the exact
-`npx rsc add` commands, and run the requirements-first 3-option decision pattern
+`npx @ericrisco/rsc add` commands, and run the requirements-first 3-option decision pattern
 for any significant choice. A skill **cannot install anything** — it recommends
 and prints commands the user runs.
 
@@ -27,11 +27,11 @@ usually does NOT want `fastapi`/`nextjs` unless they're also building software.
 
 ## What to print
 
-One `npx rsc add` line per recommendation (or batch them on one line), each with
+One `npx @ericrisco/rsc add` line per recommendation (or batch them on one line), each with
 its *why* in the user's language and level.
 
 ```text
-npx rsc add <skill> [<skill> ...]
+npx @ericrisco/rsc add <skill> [<skill> ...]
 ```
 
 ### Sample printout — software, full-stack web app with marketing
@@ -40,11 +40,11 @@ npx rsc add <skill> [<skill> ...]
 Based on what you described (a web app with a backend, a Next.js UI, a landing
 page, and you want to ship it securely), install these:
 
-npx rsc add harness        # the control plane — scaffolds and governs the workspace
-npx rsc add fastapi postgresdb   # the API and the database
-npx rsc add nextjs design  # the web UI people see
-npx rsc add marketing      # the words for your landing page
-npx rsc add secure-coding deployment   # ship it safely
+npx @ericrisco/rsc add harness        # the control plane — scaffolds and governs the workspace
+npx @ericrisco/rsc add fastapi postgresdb   # the API and the database
+npx @ericrisco/rsc add nextjs design  # the web UI people see
+npx @ericrisco/rsc add marketing      # the words for your landing page
+npx @ericrisco/rsc add secure-coding deployment   # ship it safely
 
 Once they're installed, run the harness skill and I'll build the project structure.
 ```
@@ -55,9 +55,9 @@ Once they're installed, run the harness skill and I'll build the project structu
 You're organizing how your agency runs — client emails, contracts, invoicing,
 and you want it all findable. That's a non-code harness; install:
 
-npx rsc add harness        # your 01-TOOLS (connections) + 02-DOCS (your second brain)
-npx rsc add secure-coding deployment   # connect email, payments, drive — and keep credentials safe
-npx rsc add marketing      # for the proposals, decks and copy you send clients
+npx @ericrisco/rsc add harness        # your 01-TOOLS (connections) + 02-DOCS (your second brain)
+npx @ericrisco/rsc add secure-coding deployment   # connect email, payments, drive — and keep credentials safe
+npx @ericrisco/rsc add marketing      # for the proposals, decks and copy you send clients
 
 Once installed, run the harness skill and I'll set up the structure that holds it all.
 ```
@@ -67,10 +67,10 @@ Once installed, run the harness skill and I'll set up the structure that holds i
 ```text
 You want an AI agent that answers questions over your own documents. Install:
 
-npx rsc add harness            # the control plane
-npx rsc add building-agents    # agent loops, tools, RAG
-npx rsc add fastapi postgresdb # an API + database to serve it
-npx rsc add secure-coding deployment   # ship it safely
+npx @ericrisco/rsc add harness            # the control plane
+npx @ericrisco/rsc add building-agents    # agent loops, tools, RAG
+npx @ericrisco/rsc add fastapi postgresdb # an API + database to serve it
+npx @ericrisco/rsc add secure-coding deployment   # ship it safely
 
 Then run the harness skill.
 ```

package/skills/orient/evals/cases.yaml

@@ -41,7 +41,7 @@ should_not_trigger:
     why: "Root-cause work owned by debug; orient does not take over the task itself."
 
 capability:
-  - scenario: "The user just ran `npx rsc add postgresdb` and says 'ya está, ¿y ahora qué?'. The profile shows accompaniment_level L0. Show how orient closes the turn."
+  - scenario: "The user just ran `npx @ericrisco/rsc add postgresdb` and says 'ya está, ¿y ahora qué?'. The profile shows accompaniment_level L0. Show how orient closes the turn."
     must_include:
       - "Situates the user on the map ('📍 dónde estás' / what is built vs missing)"
       - "States what just happened in one plain-language line ('✅ instalaste la base de datos')"

package/skills/sdd-init/SKILL.md

@@ -57,7 +57,7 @@ If any runner is detected, set `testing.strict_tdd: true`. Strict TDD means impl
 Refresh the project registry:
 
 ```bash
-npx rsc registry refresh
+npx @ericrisco/rsc registry refresh
 ```
 
 This writes:
@@ -69,6 +69,19 @@ This writes:
 
 Later phases use this as a cheap index: id, trigger, tags, path, installed/available, hash. Do not load every skill into context. Select the few matching the phase and stack, then digest them into compact rules for subagents.
 
+## Equip the repo — install the skills this stack needs
+
+Calibration is the moment to make sure the relevant skills are actually present, not just indexed. Detect → propose → install:
+
+1. **Detect what this repo needs.** Use the stack you just detected, or ask the CLI: `npx @ericrisco/rsc consult "<one line: stack + what we're building>"`. Map signals to skills — e.g. `next`→`nextjs`+`design`, `go.mod`→`go`, FastAPI→`fastapi`, `*.sql`/Prisma→`postgresdb`/`prisma-orm`, Stripe→`stripe`, Dockerfile/CI→`docker`/`github-actions`, tests→`testing-*`/`e2e-testing`. The SDD phase skills (`specify`…`ship`) should already be present from `--profile core`; install any that are missing.
+2. **Show the shortlist + confirm.** List the skills with a one-line *why* each, matched to the accompaniment dial, and get a one-word confirm before touching their environment.
+3. **Install them yourself.** You have a terminal — run it via Bash:
+   ```bash
+   npx @ericrisco/rsc add <skill> [<skill> ...]
+   ```
+   If you genuinely cannot run a shell, print the exact command and ask the user to paste it in another terminal tab.
+4. **Flag the new session.** Newly installed skills load at the START of a session. Tell the user: *"Instaladas. Abre una pestaña/sesión nueva de tu asistente (o recarga) en esta carpeta para que se activen."* Then refresh the registry again so `installed/available` is accurate.
+
 ## Config Shape
 
 Write `02-DOCS/wiki/sdd/config.yaml` in this shape:
@@ -129,7 +142,7 @@ End with the standard SDD result envelope:
       "Use .rsc/skill-registry.json as the cheap skill index."
     ]
   },
-  "evidence": ["npx rsc registry refresh", "detected test commands recorded"]
+  "evidence": ["npx @ericrisco/rsc registry refresh", "detected test commands recorded"]
 }
 ```
 

package/skills/sdd-init/evals/cases.yaml

@@ -38,6 +38,6 @@ capability:
       - "Writes 02-DOCS/wiki/sdd/config.yaml, not an openspec/ folder."
       - "Sets testing.strict_tdd true because a runner exists and records apply/verify commands."
       - "Asks or defaults execution_mode, artifact_store, review budget and delivery strategy."
-      - "Runs or instructs npx rsc registry refresh and records .rsc/skill-registry.json as registry_path."
+      - "Runs or instructs npx @ericrisco/rsc registry refresh and records .rsc/skill-registry.json as registry_path."
       - "Distinguishes itself from init and harness."
       - "Ends with the standard result envelope including skill_resolution and evidence."

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. |

package/skills/suggest/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: suggest
-description: "Always-on. Use whenever the current task would clearly benefit from an rsc skill that is not yet installed — detect the gap, name the skill, and (with a one-word confirm) install it via `npx rsc add <id>`. Triggers on any task that maps to a known rsc capability the session lacks: building a web/app/API, a database, security, deployment, agents, content, or connecting/documenting a company."
+description: "Always-on. Use whenever the current task would clearly benefit from an rsc skill that is not yet installed — detect the gap, name the skill, and (with a one-word confirm) install it via `npx @ericrisco/rsc add <id>`. Triggers on any task that maps to a known rsc capability the session lacks: building a web/app/API, a database, security, deployment, agents, content, or connecting/documenting a company."
 tags: [suggest, detect, install, meta, always-on]
 recommends: []
 profiles: [minimal, core, full]
@@ -14,14 +14,14 @@ When the current task would clearly benefit from an rsc skill that is **not inst
 
 1. Name it in plain language: "Para esto va bien `<id>`, que aún no tienes."
 2. Ask one short confirm: "¿La instalo? (sí/no)".
-3. On yes, run `npx rsc add <id>` (Bash). Then continue the task.
+3. On yes, run `npx @ericrisco/rsc add <id>` (Bash). Then continue the task.
 
 Rules:
 
 - Installing changes the user's environment — always confirm first.
-- To know what exists, run `npx rsc consult "<the task>"` instead of guessing.
-- For a project-level view, prefer `.rsc/skill-registry.json` when present; if it is missing or stale, suggest `npx rsc registry refresh`. This is a cheap index, not a reason to load every skill.
-- Never recommend something already installed (`npx rsc list`).
+- To know what exists, run `npx @ericrisco/rsc consult "<the task>"` instead of guessing.
+- For a project-level view, prefer `.rsc/skill-registry.json` when present; if it is missing or stale, suggest `npx @ericrisco/rsc registry refresh`. This is a cheap index, not a reason to load every skill.
+- Never recommend something already installed (`npx @ericrisco/rsc list`).
 - One suggestion at a time. Don't interrupt the flow for nice-to-haves.
 
 ## Orientación (siempre)

package/skills/suggest/evals/README.md

@@ -10,5 +10,5 @@ skill (and stays quiet when the task needs nothing new).
 | "renombra esta variable" | no suggestion (trivial, nothing to install) |
 
 A pass = the detector names the expected skill, asks a one-word confirm, and on
-"sí" runs `npx rsc add <id>`. It must never auto-install without confirmation and
-must not recommend a skill already in `npx rsc list`.
+"sí" runs `npx @ericrisco/rsc add <id>`. It must never auto-install without confirmation and
+must not recommend a skill already in `npx @ericrisco/rsc list`.

package/skills/suggest/evals/cases.yaml

@@ -2,12 +2,12 @@ skill: suggest
 
 # The always-on detector. It fires when the current task would clearly benefit
 # from an rsc skill that is NOT yet installed, names it, and (with confirmation)
-# runs `npx rsc add <id>`. It should stay silent for trivial work and defer to a
+# runs `npx @ericrisco/rsc add <id>`. It should stay silent for trivial work and defer to a
 # skill that already owns the task.
 
 should_trigger:
   - prompt: "Ayúdame a montar la tabla de pedidos en la base de datos."
-    why: "A database task with no DB skill present — the detector should propose `npx rsc add postgresdb` before diving in."
+    why: "A database task with no DB skill present — the detector should propose `npx @ericrisco/rsc add postgresdb` before diving in."
 
   - prompt: "Quiero publicar mi web online, creo que con Docker."
     why: "A deployment task with no deploy skill present — propose installing `deployment`."
@@ -46,6 +46,6 @@ capability:
     must_include:
       - "Names the missing skill in plain language ('para esto va bien `postgresdb`, que aún no tienes')"
       - "Asks a single short confirmation (sí/no) before doing anything — never auto-installs"
-      - "On confirmation, runs `npx rsc add postgresdb` via Bash, then continues the original task"
-      - "Checks what is already installed (npx rsc list) and never proposes a skill the user already has"
+      - "On confirmation, runs `npx @ericrisco/rsc add postgresdb` via Bash, then continues the original task"
+      - "Checks what is already installed (npx @ericrisco/rsc list) and never proposes a skill the user already has"
       - "Makes at most one suggestion and does not interrupt the flow for nice-to-haves"