@ericrisco/rsc 2.0.20 → 2.2.0

package/skills/specify/SKILL.md

@@ -52,18 +52,17 @@ If you cannot state a requirement without naming the technology, that is a real
 
 ## Model tier — `balanced` (opt-in routing)
 
-This phase's default model tier is **`balanced`** — it drafts the what/why spec through dialogue, not architecture. Routing is **off** unless `models.enabled: true` in `02-DOCS/wiki/sdd/config.yaml`. When on: resolve this phase's tier (`models.overrides` wins over `models.phases`), map it to a model via `models.tiers`, and apply per `../sdd/references/model-routing.md` — announce the switch per the accompaniment dial when it differs from the session model, and dispatch any `Task`/`parallel` subagents on that model. Routing off or no profile → honor the session model silently. Never fake a switch a tool can't make; skip routing on a one-line change.
+This phase's default model tier is **`balanced`** — it drafts the what/why spec through dialogue, not architecture. Routing is **off** unless `models.enabled: true` in `02-DOCS/wiki/sdd/config.yaml`. When on: resolve this phase's tier (`models.overrides` wins over `models.phases`), map it to a model via `models.tiers`, and apply per `../sdd/references/model-routing.md` — announce the switch in one line when it differs from the session model, and dispatch any `Task`/`parallel` subagents on that model. Routing off or no profile → honor the session model silently. Never fake a switch a tool can't make; skip routing on a one-line change.
 
-## Read the room first (accompaniment dial)
+## Read the room first (register)
 
-Before asking anything, read `02-DOCS/wiki/harness/user-profile.md` for the technical level and accompaniment level, and adapt:
+Before asking anything, read `technical_level` in `02-DOCS/wiki/harness/user-profile.md`. It picks the register — technical terms, or plain words with everyday analogies — and nothing else; the method is the same for every reader:
 
-- **L0 "cavernícola"** — infer aggressively from the intent and any existing wiki/constitution. Ask only the questions whose answer would change the contract. Draft, show, move on.
-- **L1 "breve"** — one line of *why* per question; ask the few that genuinely matter.
-- **L2 "explica decisiones"** — justify each requirement as you record it; surface the trade-offs you inferred.
-- **L3 "acompañamiento total"** — explain what a spec is and is not, walk every section, ask freely (still one round per frontier, never crossing a dependency), confirm each answer before recording it. Ideal for non-technical users.
+- Infer aggressively from the intent and any existing wiki/constitution. Ask only the questions whose answer would change the contract — one round per frontier, never crossing a dependency.
+- Give one line of *why* per question, in the `orient` voice; record each requirement with the trade-off you inferred.
+- For a `non-technical` reader, say in one sentence what a spec is, and phrase each option as a concrete example to react to.
 
-If no profile exists, default to non-technical framing and keep questions plain. Never assume fluency.
+If no profile exists, use analogies and keep questions plain. Never assume fluency.
 
 ## FRAME before you ask anything — from `idea-refinement`
 
@@ -171,7 +170,7 @@ Run these in order. It is a collaborative dialogue, not a form you fill in silen
 7. WRITE the spec         → 02-DOCS/wiki/sdd/specs/<slug>.md (WHAT/WHY), index it in 02-DOCS/wiki/index.md
                             (the Knowledge map; root CLAUDE.md keeps only a short pointer), commit if a repo
 8. SELF-REVIEW            → run the EXIT GATE (below) until green; scan for contradictions, ambiguity,
-                            scope creep; fix inline. On L2/L3 or high risk, add a FRESH-EYES review
+                            scope creep; fix inline. On a non-trivial or high-risk spec, add a FRESH-EYES review
 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.
 ```
@@ -197,10 +196,10 @@ the section that failed and fix it before step 9.
 A gate that has never been seen fail is not known to work, so this one ships with the test that
 watches it fail and pass (`tests/spec-gate.test.js`).
 
-### Fresh-eyes spec review (step 8, scaled to the dial)
+### Fresh-eyes spec review (step 8, scaled to the stakes)
 
 The author's own context is blind to its own gaps — the same mind that wrote the spec self-reviews it
-with the same blind spots. For an L2/L3 user or a **high-risk** spec (multi-subsystem, security/data,
+with the same blind spots. For any spec beyond a small, low-risk one — and always for a **high-risk** spec (multi-subsystem, security/data,
 irreversible, or large scope), dispatch a **fresh-context subagent** to read the written spec cold,
 *before* the user-approval gate (step 9), and fold its findings in:
 
@@ -213,7 +212,7 @@ irreversible, or large scope), dispatch a **fresh-context subagent** to read the
 - **It returns** `Approved` or `Issues found` with a short list; you fix the real ones inline, then
   proceed to step 9.
 
-**Skip it** for L0/L1 on a small, low-risk spec — the self-review scan is enough there; don't spin up
+**Skip it** on a small, low-risk spec — the self-review scan is enough there; don't spin up
 a subagent to vet a two-paragraph spec. Like the rest of the chain, ceremony scales to the stakes.
 
 ### Approval is its own exchange (step 9)
@@ -382,11 +381,11 @@ If `clarify` surfaces answers, they get baked back into this same spec file. Onl
 - `../constitution/SKILL.md` — the project principles this spec inherits as constraints.
 - `../clarify/SKILL.md` — the next phase: resolves the Points to clarify and de-risks the spec.
 - `../plan/SKILL.md` — turns the de-risked spec into a technical implementation plan (the HOW).
-- `../harness/SKILL.md` — the 02-DOCS wiki + accompaniment dial + decisions log this skill honors.
+- `../harness/SKILL.md` — the 02-DOCS wiki + user profile + decisions log this skill honors.
 - `references/spec-template.md` — the exact section template written to `02-DOCS/wiki/sdd/specs/<slug>.md`.
 - `references/eliciting-requirements.md` — inference checklist + the frontier-round elicitation pattern.
 
 ## Orientación (siempre)
 
-Cierra cada turno con el **bloque-brújula** (📍 dónde estás · ✅ qué hiciste · 🧭 por qué · ➡️ siguiente, terminando en pregunta), calibrado al dial de `02-DOCS/wiki/harness/user-profile.md`. **Nunca termines en seco.** Protocolo completo: skill `orient` → `skills/orient/references/orientation-contract.md`. (Defiere a `suggest` el "¿instalo la skill que falta?".)
+Habla con la voz de `orient`: frases cortas, una idea por frase, y cada respuesta se entiende sola. Registro técnico o con analogías según `technical_level` en `02-DOCS/wiki/harness/user-profile.md`. Cierra cada turno con el **bloque-brújula** (📍 dónde estás · ➡️ siguiente, terminando en pregunta; ✅ y 🧭 cuando hay algo hecho o decidido). **Nunca termines en seco.** Protocolo completo: skill `orient` → `skills/orient/references/orientation-contract.md`. (Defiere a `suggest` el "¿instalo la skill que falta?".)
 

package/skills/specify/evals/cases.yaml

@@ -63,7 +63,7 @@ should_not_trigger:
 capability:
   - scenario: "A user says: 'I want to add magic-link (passwordless) login.' There is a constitution at 02-DOCS/wiki/sdd/constitution.md but no spec yet. Produce the spec."
     must_include:
-      - "Reads the accompaniment level from 02-DOCS/wiki/harness/user-profile.md and the constitution first, inferring everything it can before asking, then asks only contract-changing gaps — the whole FRONTIER in one numbered round, each with its recommendation, and nothing whose answer depends on another question open in that same round."
+      - "Reads technical_level from 02-DOCS/wiki/harness/user-profile.md and the constitution first, inferring everything it can before asking, then asks only contract-changing gaps — the whole FRONTIER in one numbered round, each with its recommendation, and nothing whose answer depends on another question open in that same round."
       - "Stays strictly WHAT/WHY: no framework, token format, database table, endpoint shape, email provider, library, or file path appears in the spec — implementation-laden answers are flagged as points to clarify instead of guessed."
       - "Produces the spec sections: Problem & why, Cost of not building it, The cheapest alternative, Goals, Non-goals / out of scope, Users & context, Behaviour (main + edge + error paths), Acceptance criteria, Points to clarify — and neither of the two doubt sections is left as a formality: 'Cost of not building it' names a concrete consequence, and 'The cheapest alternative' names something that would solve most of it without building this, plus why that is not enough."
       - "Writes testable acceptance criteria in Given/When/Then form that verify could later check (e.g. expired-link refusal, unknown-email revealing nothing)."

package/skills/specify/references/eliciting-requirements.md

@@ -22,7 +22,7 @@ and the intent itself. Only what survives as unknown becomes a question or a
 - **Boundaries** — what's adjacent but deliberately excluded? Derive non-goals
   from the constitution's scope and quality bars.
 - **Happy path** — the common-case behaviour is usually inferable from the
-  intent; write it, then test it with the user if L2/L3.
+  intent; write it, then test it with the user.
 - **Edges** — empty / none / one / many / max, concurrent, repeated, expired,
   unauthorized. Walk these mechanically; each is a candidate criterion.
 - **Errors** — what does the user see when it fails, and what must NOT be
@@ -77,15 +77,15 @@ moved is worse than no answer, because it looks settled.
 
 Phrase by register:
 
-- **Non-technical / L3** — plain language, one concept, offer a concrete
+- **Non-technical** — plain language, one concept, offer a concrete
   example to react to rather than an open void:
   > "When someone's link has expired, should they be able to ask for a fresh
   > one right there, or is that a separate step?"
-- **Technical / L0-L1** — terse, decision-shaped:
+- **Technical** — terse, decision-shaped:
   > "Expired-link recovery in scope, or defer?"
 
-Always: emit the round → wait → record each answer in its section → confirm at
-L2/L3 → recompute the frontier. The thing to avoid was never two questions in
+Always: emit the round → wait → record each answer in its section → confirm it
+→ recompute the frontier. The thing to avoid was never two questions in
 one message; it was ten questions whose answers depend on each other, which is
 what crossing a dependency produces.
 

package/skills/suggest/SKILL.md

@@ -15,9 +15,6 @@ are the one piece guaranteed to be present before any other skill is matched. Tw
 1. **Classify every turn into one of three lanes** before anything is written.
 2. **Keep the session equipped** — spot the skill the task needs but the user does not have.
 
-Everything below is what only this layer can do. The method behind each rule lives in the skill that
-owns it; this is the pointer, not the manual.
-
 ---
 
 ## 1. The decisor: classify the turn before acting
@@ -110,8 +107,8 @@ Offer once per session. Never mention any of it when the harness is healthy.
 Before handling the first request of a session, check the workspace:
 
 - No `02-DOCS/wiki/harness/user-profile.md` **and** no `.rsc/.no-harness` → the harness has never
-  been set up here. Invoke `init` first; it opens with the two gauging questions (technical level +
-  accompaniment dial). Do not start the user's task before first contact is done.
+  been set up here. Invoke `init` first; it opens with one question: technical terms or analogies.
+  Do not start the user's task before first contact is done.
 - The user declines a harness here ("sin harness", "solo código") → create an empty
   `.rsc/.no-harness`, confirm in one line, and never auto-start `init` in this repo again.
 - Once the profile exists, this gate is inert. Never re-onboard.
@@ -122,7 +119,4 @@ Define a term at first use; never give a command, flag or path without saying wh
 
 ## Orientación (siempre)
 
-Cierra cada turno con el **bloque-brújula** (📍 dónde estás · ✅ qué hiciste · 🧭 por qué · ➡️ siguiente,
-terminando en pregunta), calibrado al dial de `02-DOCS/wiki/harness/user-profile.md`. Nunca termines
-en seco. Protocolo completo: skill `orient` → `skills/orient/references/orientation-contract.md`.
-(Defiere a este mismo cuerpo, §2, el "¿instalo la skill que falta?".)
+Habla con la voz de `orient`: frases cortas, una idea por frase, al grano, y cada respuesta se entiende sola. Registro técnico o con analogías según `technical_level` en `02-DOCS/wiki/harness/user-profile.md`. Cierra cada turno con el **bloque-brújula** (📍 dónde estás · ➡️ siguiente, terminando en pregunta; ✅ y 🧭 cuando hay algo hecho o decidido). **Nunca termines en seco.** Protocolo completo: skill `orient` → `skills/orient/references/orientation-contract.md`. (Defiere a §2 el "¿instalo la skill que falta?".)

package/skills/suggest/evals/cases.yaml

@@ -59,7 +59,7 @@ capability:
       - "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"
 
-  - scenario: "Mid-conversation, after base install, the user says 'quiero montar una pagina web para vender cursos online'. `init`, `harness`, `orient`, `suggest`, and `bro` are already installed; `nextjs` is not. Show how rsc-suggest behaves."
+  - scenario: "Mid-conversation, after base install, the user says 'quiero montar una pagina web para vender cursos online'. `init`, `harness`, `orient`, `suggest`, and `unslop` are already installed; `nextjs` is not. Show how rsc-suggest behaves."
     must_include:
       - "Treats the message as in-agent capability intent, not as a CLI-only consult task"
       - "Runs `npx @ericrisco/rsc catalog --available` to see the not-installed skills (already excludes installed `init`/`harness`)"

package/skills/tasks/SKILL.md

@@ -33,12 +33,11 @@ announcement rules. Routing off or no profile → honor the session model silent
 
 ## Read the harness profile first
 
-Read `02-DOCS/wiki/harness/user-profile.md` before producing anything and match
-the accompaniment dial: **L0** emit the task table and nothing else; **L1** add
-one line of *why this slicing* above it; **L2** justify the ordering and the
-parallel markers as you go, flagging the risky tasks; **L3** walk each dependency
-and confirm the done-checks make sense to the user before writing. No profile →
-assume non-technical and let `init` gauge the level; never invent one.
+Read `02-DOCS/wiki/harness/user-profile.md` before producing anything: its
+`technical_level` sets the register (technical terms, or plain words with
+analogies). The task table is always complete. In chat, speak in the `orient`
+voice: one line of *why this slicing*, then flag the risky tasks. No profile →
+use analogies and ask once "technical or with analogies?"; never invent one.
 
 ## Inputs (refuse to start without them)
 
@@ -263,4 +262,4 @@ was to let `analyze` audit it cheaply *before* code exists.
 
 ## Orientación (siempre)
 
-Cierra cada turno con el **bloque-brújula** (📍 dónde estás · ✅ qué hiciste · 🧭 por qué · ➡️ siguiente, terminando en pregunta), calibrado al dial de `02-DOCS/wiki/harness/user-profile.md`. **Nunca termines en seco.** Protocolo completo: skill `orient` → `skills/orient/references/orientation-contract.md`. (Defiere a `suggest` el "¿instalo la skill que falta?".)
+Habla con la voz de `orient`: frases cortas, una idea por frase, y cada respuesta se entiende sola. Registro técnico o con analogías según `technical_level` en `02-DOCS/wiki/harness/user-profile.md`. Cierra cada turno con el **bloque-brújula** (📍 dónde estás · ➡️ siguiente, terminando en pregunta; ✅ y 🧭 cuando hay algo hecho o decidido). **Nunca termines en seco.** Protocolo completo: skill `orient` → `skills/orient/references/orientation-contract.md`. (Defiere a `suggest` el "¿instalo la skill que falta?".)

package/skills/tasks/evals/cases.yaml

@@ -65,7 +65,7 @@ capability:
   - scenario: "An approved plan exists at 02-DOCS/wiki/sdd/plans/auth.md (login + sessions + a users migration, pytest as the testing strategy) and a spec at specs/auth.md. Break it into a task list."
     must_include:
       - "Confirms the inputs first: plan, spec, AND constitution must exist; if the plan were missing it would STOP and route to `plan` rather than slice from intent."
-      - "Reads 02-DOCS/wiki/harness/user-profile.md for the accompaniment level and adapts verbosity (L0 table-only … L3 explain the slicing/dependencies)."
+      - "Reads technical_level from 02-DOCS/wiki/harness/user-profile.md and picks the register; the table is complete either way, and the chat adds only one line of why-this-slicing plus the risky tasks."
       - "Emits sequential zero-padded stable IDs (T001, T002… — no hyphen, GitHub Spec Kit canon) with the six well-formed fields: ID, a separate [P] marker field after the ID, imperative title, done-check, depends-on, and a trace to a spec section."
       - "Every done-check is a LITERAL runnable command or checkable observation (e.g. `pytest tests/auth/test_login.py` green; `alembic upgrade head` applies; bad password → 401) — never 'login works'."
       - "Orders by dependency (migration/schema → data → service → API), so no task precedes what it depends on; marks `[P]` only on file/state-disjoint tasks and defaults to sequential when unsure."

package/skills/unslop/SKILL.md

@@ -1,17 +1,44 @@
 ---
 name: unslop
-description: "Use when a written text must be audited against a named catalogue of AI tells before it ships: puffery, `not just X but Y`, the rule of three, em dashes, filler, hedging, abstract metaphor nouns. Names each hit and fixes it. NOT the register rewrite in the user's own voice (that is `bro`), NOT a reusable voice guide (that is `brand-voice`)."
-tags: [unslop, ai-tells, editing, audit, slop, publish-check, revisar-texto]
-recommends: [bro, brand-voice, technical-writing]
+description: "Use when a text that leaves the session (email, post, README, message, landing copy) must sound like a person and carry no AI tells: rewrites it in the user's language fitted to the channel and relationship, and audits it against a named catalogue of tells (puffery, `not just X but Y`, rule of three, em dashes, filler, hedging). Fires on 'bro', 'hazlo más humano', 'que no suene a IA', 'más natural', 'unslop this'. NOT how the harness talks to the user (that is `orient`), NOT a reusable voice guide (that is `brand-voice`)."
+tags: [unslop, human-writing, humano, natural-language, plain-language, ai-tells, editing, rewrite, bro, revisar-texto]
+recommends: [brand-voice, technical-writing]
 profiles: [minimal, core, full]
 origin: risco
 ---
 
-# unslop: the named-tell audit a text passes before it ships
+# unslop: text that leaves the session sounds like a person
 
-`bro` decides how a text should *sound*. This decides whether a text still carries the marks of a
-machine, tell by named tell, on the words that are actually there. Run it on anything about to leave
-the session: a README, a post, an email, a landing page, a commit body.
+Two passes over a text someone else will read: the **register** (sound like a person, in this
+language, for this relationship and channel) and the **named-tell audit** (no marks of a machine,
+tell by tell). Run it on anything about to leave the session: a README, a post, an email, a landing
+page, a commit body. How the harness talks to the user is `orient`, not this.
+
+## Find the source without ceremony
+
+A bare "bro", "unslop", "write like a human", "hazlo más natural" points to the assistant's last
+answer. If the user pasted text, work on that. If they asked for new copy, draft it directly. Ask for
+text only when no source exists.
+
+## The register pass
+
+1. **Preserve the payload.** Names, facts, numbers, links, commitments, constraints, uncertainty and
+   necessary warnings stay. Never invent evidence, opinions, anecdotes or certainty to make it flow.
+2. **Match the room.** The user's language, fitted to audience, relationship and channel. A natural
+   legal notice is still precise; a natural Slack message can be loose. Human is not always casual.
+3. **Cut the bot-shaped scaffolding.** Throat-clearing, needless summaries, repeated conclusions,
+   corporate filler, fake enthusiasm, headings or bullets that do not help the reader navigate.
+4. **Restore a real cadence.** Concrete verbs, direct sentences, natural contractions. The words a
+   person in this context would choose, without manufactured slang, typos or choppy fragments.
+
+| Aim | The result |
+| --- | --- |
+| Plain, not simplistic | Easy to follow without losing the idea |
+| Concise, not incomplete | No padding; every load-bearing fact remains |
+| Warm, not performative | Appropriate care without canned empathy |
+| Specific, not decorated | Concrete nouns and verbs instead of hype |
+
+When a text needs both passes: audit first, register last.
 
 ## The pass
 
@@ -96,6 +123,9 @@ Voiceless writing is as obvious as slopped writing. After the cuts, put somethin
 | Strip a term because it sounds technical | Precision lost to style is a defect | Keep the term, explain it once |
 | Touch code, commands, URLs, quotes or regulated wording | Those are not prose | Leave them byte for byte |
 | Claim the result will pass an AI detector | Nobody can promise that | Promise named tells removed, nothing more |
+| Add typos, slang or filler to seem human | It performs humanity and sounds less credible | Match the actual relationship and channel |
+| Use the same casual voice for every audience | A client email, a README and a condolence need different registers | Infer the room before choosing the cadence |
+| Announce and justify every edit | The preamble is the friction the user asked to remove | Lead with the finished words |
 | Flatten a voice the author chose on purpose | Some authors do write long, warm or formal | Match the intended tone, cut only the machine marks |
 
 ## Output boundary
@@ -106,9 +136,8 @@ email or a document by accident.
 
 ## Where this ends
 
-- **`bro`** owns the register pass: make it sound like a person, in the user's language, fitted to the
-  channel and the relationship. A bare "bro" after an answer is always `bro`. This skill is the named
-  audit of a text that already exists, before it goes out.
+- **`orient`** owns how the harness talks to the user: STE-style, short, every answer stands alone.
+  This skill is for text the user sends to someone else.
 - **`brand-voice`** owns the standing voice system across writers and channels.
 - **`technical-writing`** owns structure: what belongs in a tutorial, a reference, a README.
 - **`landing-copy`** owns conversion architecture. Clean its words only after it has chosen them.

package/skills/unslop/evals/README.md

@@ -1,18 +1,18 @@
 # Evals — unslop
 
-The claim under test is the boundary as much as the capability. `bro` sits directly next to this
-skill in the base install, and a description that blurs them costs every user two owners for one
-turn. Half the negatives here exist to prove the split holds.
+The claim under test is the boundary as much as the capability. `unslop` absorbed the retired `bro`,
+so it owns both the register pass and the audit of text that leaves the session. Its neighbour is
+`orient`, which owns how the harness talks to the user. The negatives prove that split holds.
 
 ## Triggering
 
 Load only `unslop` and run every prompt in 3–5 fresh sessions. A positive passes when `unslop` loads
 in a majority of trials; a negative passes when it stays quiet and the declared `route_to` skill is
-the real owner. Require at least 90% accuracy, and treat any failure on the two `bro` negatives as
-blocking rather than statistical: those are the cases the split was designed for.
+the real owner. Require at least 90% accuracy, and treat any failure on the `orient` negative or on
+the two former `bro` positives as blocking rather than statistical.
 
-Run the mirror direction too. `bro`'s own suite carries a negative that routes here; both must pass
-in the same round, or the boundary only exists on one side.
+Run the mirror direction too. `orient`'s own suite carries a negative that routes here; both must
+pass in the same round, or the boundary only exists on one side.
 
 ## Capability
 

package/skills/unslop/evals/cases.yaml

@@ -1,9 +1,8 @@
 skill: unslop
 
-# `unslop` is the named-tell audit of a text that already exists, run before it
-# ships. `bro` is the register pass: sound like a person, in the user's language,
-# fitted to the channel. A bare "bro" is always `bro`; "check this for AI tells
-# before I publish it" is always this skill.
+# `unslop` owns text that leaves the session: the register pass (sound like a person,
+# in the user's language, fitted to the channel) and the named-tell audit before it
+# ships. It absorbed the retired `bro`. How the harness talks to the user is `orient`.
 should_trigger:
   - prompt: "Revisa este README antes de publicarlo y quítale todo lo que huela a IA."
     why: "A pre-publication audit of an existing text is the exact contract, in the user's own words."
@@ -23,14 +22,16 @@ should_trigger:
   - prompt: "Before this goes to the client, strip the puffery and the hedging but keep every number exact."
     why: "A ship gate over existing prose with a preserve-the-facts constraint."
 
-should_not_trigger:
   - prompt: "Bro."
-    route_to: "bro"
-    why: "A bare bro after an answer is the register pass over the last message, not an audit of a supplied text."
+    why: "A bare bro after an answer is the register pass over the last message (the retired bro skill lives here now)."
 
   - prompt: "Haz que este correo suene más cercano y menos formal para un cliente de confianza."
-    route_to: "bro"
-    why: "Choosing a warmer register for a specific relationship is bro's job; no tell is being audited."
+    why: "Choosing a warmer register for a specific relationship and channel is the register pass."
+
+should_not_trigger:
+  - prompt: "No entiendo lo que me acabas de explicar, hazlo más simple."
+    route_to: "orient"
+    why: "How the harness explains things to the user is orient's voice and ladder, not a text for others."
 
   - prompt: "Define how our company should sound across the blog, support replies and job ads."
     route_to: "brand-voice"

package/skills/verify/SKILL.md

@@ -19,16 +19,13 @@ Not this phase: still writing tests or production code → `../implement/SKILL.m
 
 ## Model tier — `balanced` (opt-in routing)
 
-This phase's default model tier is **`balanced`** — it runs the checks and interprets failures with judgment. Routing is **off** unless `models.enabled: true` in `02-DOCS/wiki/sdd/config.yaml`. When on: resolve this phase's tier (`models.overrides` wins over `models.phases`), map it to a model via `models.tiers`, and apply per `../sdd/references/model-routing.md` — announce the switch per the accompaniment dial when it differs from the session model, and dispatch any `Task`/`parallel` subagents on that model. Routing off or no profile → honor the session model silently. Never fake a switch a tool can't make; skip routing on a one-line change.
+This phase's default model tier is **`balanced`** — it runs the checks and interprets failures with judgment. Routing is **off** unless `models.enabled: true` in `02-DOCS/wiki/sdd/config.yaml`. When on: resolve this phase's tier (`models.overrides` wins over `models.phases`), map it to a model via `models.tiers`, and apply per `../sdd/references/model-routing.md` — announce the switch in one line when it differs from the session model, and dispatch any `Task`/`parallel` subagents on that model. Routing off or no profile → honor the session model silently. Never fake a switch a tool can't make; skip routing on a one-line change.
 
-## Read the room first (accompaniment dial)
+## Read the room first (register)
 
-Before running anything, read `02-DOCS/wiki/harness/user-profile.md` for the technical + accompaniment level; no profile yet → default to non-technical framing. The verdict itself (pass / fail per item) never changes with the dial — only how much you explain around it.
+Before running anything, read `technical_level` in `02-DOCS/wiki/harness/user-profile.md`; no profile yet → use analogies. The verdict itself (pass / fail per item) never changes with the register — only the words around it.
 
-- **L0** — run the gate, show pass/fail and the one-line failing summary. Minimal words.
-- **L1** — add one line of *why* per failing check.
-- **L2** — narrate each gate (what lint/type/test/audit checks and why it matters here).
-- **L3** — explain every result, what each acceptance criterion means in plain language, and what the user should decide next.
+Report in the `orient` voice: pass/fail per gate, then one line of *why* per failing check, then what the user should decide next. For a `non-technical` reader, say what each failing check protects with an everyday analogy.
 
 ## The gate (run in this order)
 
@@ -229,5 +226,5 @@ A **PASS** record is the entry ticket to the next phase: **`../review/SKILL.md`*
 
 ## Orientación (siempre)
 
-Cierra cada turno con el **bloque-brújula** (📍 dónde estás · ✅ qué hiciste · 🧭 por qué · ➡️ siguiente, terminando en pregunta), calibrado al dial de `02-DOCS/wiki/harness/user-profile.md`. **Nunca termines en seco.** Protocolo completo: skill `orient` → `skills/orient/references/orientation-contract.md`. (Defiere a `suggest` el "¿instalo la skill que falta?".)
+Habla con la voz de `orient`: frases cortas, una idea por frase, y cada respuesta se entiende sola. Registro técnico o con analogías según `technical_level` en `02-DOCS/wiki/harness/user-profile.md`. Cierra cada turno con el **bloque-brújula** (📍 dónde estás · ➡️ siguiente, terminando en pregunta; ✅ y 🧭 cuando hay algo hecho o decidido). **Nunca termines en seco.** Protocolo completo: skill `orient` → `skills/orient/references/orientation-contract.md`. (Defiere a `suggest` el "¿instalo la skill que falta?".)
 

package/skills/verify/evals/cases.yaml

@@ -88,7 +88,7 @@ capability:
         - "The retry loop can spin forever" was raised in review; the implementer replied
           "not a real problem".
     must_include:
-      - "Reads the accompaniment level from 02-DOCS/wiki/harness/user-profile.md and adapts verbosity (verdict legibility unchanged by the dial)."
+      - "Reads technical_level from 02-DOCS/wiki/harness/user-profile.md and picks the register (verdict unchanged by it); reports short, with one line of why per failing check."
       - "LOCATES the three acceptance criteria and the three task done-checks from the material given, and maps each to what the implementer actually reports."
       - "Refuses to accept the implementer's summary as the gate: says the checks must be re-run and the output read, rather than trusting a reported '2 passed'."
       - "Treats the mypy SKIP as UNVERIFIED rather than a pass, and does not let 'everything else was green' stand in for the skipped layer."

package/skills/worktrees/SKILL.md

@@ -53,10 +53,10 @@ extra directory. The rest of this skill assumes a worktree; the branch path is t
 
 Run this in order. Each check prevents a class of "lost work" you can't easily undo.
 
-1. **Read the accompaniment dial** — `02-DOCS/wiki/harness/user-profile.md` gives the technical +
-   accompaniment level (L0..L3); set your volume from the table below. No profile yet → assume
-   non-technical, explain what a worktree is in one plain sentence before making one. No `02-DOCS/` at all (a worktree can be created in any git repo
-   with no rsc harness present) → skip the dial, assume non-technical, and proceed.
+1. **Read the register** — `technical_level` in `02-DOCS/wiki/harness/user-profile.md` picks
+   technical terms or plain words with analogies (see "Talking about it" below). No profile yet, or
+   no `02-DOCS/` at all (a worktree can be created in any git repo with no rsc harness present) →
+   use analogies: explain what a worktree is in one plain sentence before making one, and proceed.
 2. **Confirm you're in a git repo.** `git rev-parse --is-inside-work-tree`. If not, there's nothing
    to isolate with git — tell the user; don't fabricate a worktree.
 3. **Check the current branch.** `git rev-parse --abbrev-ref HEAD`. On `main`/`master` with work
@@ -130,8 +130,8 @@ npx @ericrisco/rsc worktrees reap
 ```
 
 Either way, the contract is identical: **after this step, the cwd is an isolated branch off a clean
-base, and the default-branch checkout is exactly as it was.** Confirm that out loud (at the dial's
-level) before handing to `implement`.
+base, and the default-branch checkout is exactly as it was.** Confirm that out loud, in
+one line, before handing to `implement`.
 
 ### Cleanup is the default, and it is not yours to judge
 
@@ -169,21 +169,17 @@ a linked worktree (`git rev-parse --git-dir` ≠ `--git-common-dir`), rule out a
 
 ## Model tier — `light` (opt-in routing)
 
-This phase's default model tier is **`light`** — isolating the workspace is mechanical git work. Routing is **off** unless `models.enabled: true` in `02-DOCS/wiki/sdd/config.yaml`. When on: resolve this phase's tier (`models.overrides` wins over `models.phases`), map it to a model via `models.tiers`, and apply per `../sdd/references/model-routing.md` — announce the switch per the accompaniment dial when it differs from the session model, and dispatch any `Task`/`parallel` subagents on that model. Routing off or no profile → honor the session model silently. Never fake a switch a tool can't make; skip routing on a one-line change.
+This phase's default model tier is **`light`** — isolating the workspace is mechanical git work. Routing is **off** unless `models.enabled: true` in `02-DOCS/wiki/sdd/config.yaml`. When on: resolve this phase's tier (`models.overrides` wins over `models.phases`), map it to a model via `models.tiers`, and apply per `../sdd/references/model-routing.md` — announce the switch in one line when it differs from the session model, and dispatch any `Task`/`parallel` subagents on that model. Routing off or no profile → honor the session model silently. Never fake a switch a tool can't make; skip routing on a one-line change.
 
-## Adapting to the dial
+## Talking about it
 
-The isolation is identical at every level; only the talking changes.
+The isolation is identical for every reader; only the words change. In the `orient` voice: state
+the branch/dir in one line, add one line of *why* a worktree over a branch (or vice-versa) for this
+case, and confirm the base ref. For a `non-technical` reader, say what a worktree is with an
+everyday analogy (a second copy of the desk, so the first one stays as it was).
 
-| Level | How `worktrees` behaves |
-| --- | --- |
-| **L0** | Create the isolated workspace, state the branch/dir in one line, hand to `implement`. No explanation. |
-| **L1** | Same, plus one line of *why* a worktree over a branch (or vice-versa) for this case. |
-| **L2** | Justify the base-ref choice and the branch-vs-worktree call; surface the dirty-tree decision explicitly. |
-| **L3** | Explain in plain language what a worktree is and why isolation protects their work; ask before touching any uncommitted changes; confirm the base ref. |
-
-At every level, a **dirty tree with the user's uncommitted work is a hard stop for a confirmation** —
-the dial controls verbosity, never whether you check before risking someone's WIP.
+A **dirty tree with the user's uncommitted work is always a hard stop for a confirmation** — no
+wish for brevity removes the check before risking someone's WIP.
 
 ## Anti-patterns → STOP
 

package/skills/worktrees/evals/cases.yaml

@@ -37,7 +37,7 @@ capability:
   - scenario: "User says: 'I'm on main with a clean tree, the plan for the order-reservation feature (slug: order-reservation) is approved, and I'm about to implement it. My editor and a dev server are open against the current files. Set up isolation.' The agent has the worktrees skill loaded and a native worktree tool available."
     must_include:
       - "Runs the pre-flight gate: confirms it's a git repo, checks current branch (main), and checks `git status --short` for tree state before creating anything"
-      - "Reads 02-DOCS/wiki/harness/user-profile.md for the accompaniment dial and matches narration to the level"
+      - "Reads technical_level from 02-DOCS/wiki/harness/user-profile.md and narrates briefly in that register (branch/dir in one line plus one line of why)"
       - "Chooses a WORKTREE over a plain branch and justifies it by the live dev server / open editor on the current files (a branch switch would yank files from the running process)"
       - "Prefers the native worktree tool (EnterWorktree-style) for creation and session-switch, naming it for the slug (feat/order-reservation); states the git `git worktree add -b feat/order-reservation … origin/<default>` fallback if no native tool exists"
       - "Branches from an up-to-date default base (fresh origin/<default>) rather than stale local HEAD, or asks which the user wants"

package/targets/_md-block.js

@@ -13,6 +13,12 @@ const MARK_END = '<!-- rsc-suggest:end -->';
 // The exact separator wireHook writes before an appended block, so unwireHook can take
 // back precisely what it gave and leave the rest of the file untouched.
 const SEAM = '\n\n';
+// Most assistants that read a rules file have no session-start hook, so nothing checks for a new rsc
+// on its own. The agent does it instead. Here and not in suggest's body: the body is paid on every
+// turn by every assistant, Claude Code included, which already checks from its hook.
+export const UPDATE_NOTE = '**rsc updates.** Claude Code, Codex, Gemini CLI, Cursor and OpenCode check for a new rsc on their '
+  + 'own. In any other assistant, run `node .rsc/auto-update.mjs` once on the first turn of a session and relay any '
+  + 'notice it prints in one line; "up to date" needs no mention.\n';
 
 export function writeSkill(id, fromDir, toPath) {
   return linkOrCopy(fromDir, toPath);
@@ -23,7 +29,7 @@ export function wireHook(paths, sourceMd, policy = {}) {
   const body = policy.codeHooks === false
     ? `# rsc-suggest — always-on operations layer\n\nRead \`02-DOCS/wiki/harness/user-profile.md\` before acting. Use \`orient\` to keep the user situated and \`suggest\` to offer a missing skill only when the current task needs it. Close with the configured orientation block.\n`
     : full;
-  const block = `${MARK_START}\n${body}\n${MARK_END}`;
+  const block = `${MARK_START}\n${body}\n${UPDATE_NOTE}\n${MARK_END}`;
   let doc = existsSync(paths.hookTarget) ? readFileSync(paths.hookTarget, 'utf8') : '';
   if (doc.includes(MARK_START)) {
     doc = doc.replace(new RegExp(`${MARK_START}[\\s\\S]*?${MARK_END}`), block);