@ericrisco/rsc 0.1.30 → 0.1.32

package/manifest.json

@@ -1,5 +1,5 @@
 {
-  "version": "0.1.30",
+  "version": "0.1.32",
   "counts": {
     "skills": 231
   },

package/package.json

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

package/skills/plan/SKILL.md

@@ -200,9 +200,22 @@ what changed — don't fork a `-v2`.
   `../postgresdb/SKILL.md`).
 - Project-wide non-negotiables (stack canon, quality bars) → `../constitution/SKILL.md`.
 
+## Always propose isolation before the build
+
+Once the plan is written, **always propose isolating the work in a git worktree/branch** before
+any code is implemented — every feature, not just the risky ones. One line, calibrated to the dial:
+
+> *"Antes de implementar, ¿aíslo este trabajo en un worktree/rama propia (`../worktrees/SKILL.md`)
+> para no tocar tu rama actual? (recomendado)"*
+
+Propose it here at the plan→build boundary so the decision is made before `implement` writes a line.
+If the user accepts, hand to `../worktrees/SKILL.md` first; if they decline, note it and continue.
+If you are already on the default branch (`main`/`master`), isolation is **not** optional — say so
+and route to `worktrees` regardless. (`implement` re-checks this as a hard gate before its first commit.)
+
 ## Next in the chain
 
-Plan written, indexed, decisions logged → hand off to **`../tasks/SKILL.md`**, which turns the
-sequencing section into an ordered, independently-verifiable task list with a done-check per task.
-If planning surfaced an ambiguity the spec never resolved, loop back to **`../clarify/SKILL.md`**
-before tasking.
+Plan written, indexed, decisions logged → propose isolation (above), then hand off to
+**`../tasks/SKILL.md`**, which turns the sequencing section into an ordered, independently-verifiable
+task list with a done-check per task. If planning surfaced an ambiguity the spec never resolved,
+loop back to **`../clarify/SKILL.md`** before tasking.

package/skills/sdd/SKILL.md

@@ -96,6 +96,29 @@ If you genuinely cannot tell which phase you are in, ask the user one question:
 - `constitution` runs **once per project**, not per feature. If `02-DOCS/wiki/sdd/constitution.md` exists, read it as guardrails and move on.
 - `clarify` and `analyze` are **gates, not paperwork**. If a spec is genuinely unambiguous and tiny, name that out loud and pass through — but the bias is to run them, because skipped gates are where drift hides.
 
+## Autopilot mode — run the whole chain on one up-front yes
+
+By default the chain pauses at its gates (spec approval, plan approval). **Autopilot** trades those
+per-phase stops for a **single up-front consent**: the user says "take it all the way" once, and the
+chain runs `specify → clarify → plan → tasks → analyze → implement → verify → review` end to end
+**without asking to continue between phases** — still writing every artifact (spec, plan, decisions)
+to `02-DOCS/wiki/sdd/` as it goes, so the work stays reviewable after the fact.
+
+**How it turns on:**
+
+- `specify` **offers it at the brainstorm boundary** ("¿lo llevo hasta el final yo solo, o paramos en cada fase?"). A yes engages autopilot for this feature.
+- Or set `sdd.autopilot: true` in `02-DOCS/wiki/sdd/config.yaml` to default it on (still surfaced once per feature).
+
+**The up-front yes IS the gate.** It satisfies the new-feature gate's "spec + plan approved before code" — approval was granted in advance, for the whole run. Do not re-ask phase by phase.
+
+**Autopilot still STOPS for these — not "continue?" nags, real forks:**
+
+- **Genuine ambiguity** that would change scope, a goal, or an acceptance criterion (never guess the product).
+- **A hard failure** it can't resolve (a red test it can't green → `debug`; an `analyze` contradiction).
+- **Destructive / irreversible / outward-facing actions** — push, merge, delete, secrets. `ship` (PR/merge) still confirms: autopilot drives the **build**, not the **release**.
+
+Run the fan-out on the `developer` subagent as usual, and narrate at the accompaniment dial's volume (L0: near-silent, just show artifacts; L3: explain each phase as it passes). Autopilot changes **when you ask**, never **what gets written** — every artifact and gate-check still happens; you just don't block on a human between them.
+
 ## Read the accompaniment dial first
 
 Before dispatching, read `02-DOCS/wiki/harness/user-profile.md` and adapt — exactly as every rsc skill does. The dial sets **how much you explain and how many questions you ask at each gate**, not whether the gates exist.

package/skills/specify/SKILL.md

@@ -22,6 +22,11 @@ Fire on the **faintest** sign the user is thinking about a new feature or change
 
 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`.
 
+**Offer autopilot once, right here.** At this boundary, propose how to run the rest of the chain:
+> *"¿Quieres que lo lleve hasta el final yo solo — spec → plan → código → verify, parando solo si algo es ambiguo — o prefieres que pare a que apruebes en cada fase?"*
+
+A **yes engages autopilot** (`../sdd/SKILL.md`): you still write the spec and every artifact, but you auto-advance through the phases without re-asking — that up-front yes is the approval that satisfies the hard gate above, for the whole run. A **no** (or silence) keeps the default gated flow: write the spec, hand to `clarify`/`plan`, stop for approval before code. Either way the spec gets written; autopilot only changes whether you pause *between* phases — and it still stops for genuine ambiguity, hard failures, or destructive/outward actions (ship still confirms). If `sdd.autopilot: true` in config, autopilot is the default — still surface it once.
+
 ## 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.

package/skills/suggest/SKILL.md

@@ -19,7 +19,7 @@ You are always loaded — your body is injected into context at the start of **e
 
 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.
+**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. (Exception: if the user engaged **SDD autopilot**, that single up-front consent IS the approval for the whole run — auto-advance through the phases without re-asking; see `../sdd/SKILL.md`.)
 
 **Where does this turn go? When unsure, choose `specify` — the safe default.**