init

# init — the rsc-skills Front Door *The very first thing you run. It meets the user where they are — assuming non-technical until told otherwise — figures out what they actually want, installs the right skills, and hands off to `harness` to build the workspace.* Think of `init` as the receptionist: it learns who you are and what you need, writes that down where every other skill can read it, and walks you to the right room. The boundary is fixed: **`init` writes only the user-profile and decisions log under `02-DOCS/wiki/harness/`, plus the `CLAUDE.md` Knowledge-map link.** Every other `01-TOOLS/` + `02-DOCS/` scaffold belongs to `harness`. It is **domain-agnostic**. The thing being built or governed may be software on any stack, or a non-code harness — running a company, an ops desk, a research program, a knowledge base, a content operation. No code required; the same structure governs it. Never assume "project" means "code". ## First contact: one question, set before anything else The whole harness talks differently depending on this answer. Nothing — no discovery, no recommendation — happens before the profile exists and `CLAUDE.md` links it. **Step 1 — Ask the register.** Literally the first thing you say, before any discovery. Ask once, in their language: > "¿Te hablo en lenguaje técnico o con analogías?" > "Should I talk to you in technical terms or with analogies?" Record `technical_level: technical` (technical terms used directly) or `non-technical` (plain words and everyday analogies). `mixed` stays valid in older profiles and reads like `non-technical`. No clear answer → `non-technical`. There is no second question: every skill speaks in the one voice `orient` owns (short sentences, one idea each, every answer understandable on its own), and this value only picks its register. Full rules and file formats → `references/accompaniment-and-profile.md`. **Step 2 — Persist immediately.** Before discovery, before any recommendation: - `02-DOCS/wiki/harness/user-profile.md` — the living profile (register, goals, context, constraints). - `02-DOCS/wiki/harness/decisions.md` — append-only. Entries are never edited or deleted. - Root `CLAUDE.md` → a **short** `## Knowledge map` pointer: those two read-first entries plus a "full index → `02-DOCS/wiki/index.md`" line. Keep it tiny; it loads on every turn, and every other index entry belongs in the wiki index. Create `CLAUDE.md` if absent, additive only — never delete user content. Greenfield? Create just `02-DOCS/wiki/harness/` to hold those two files. That plus the link is everything `init` writes. **Step 3 — Propose the developer model.** rsc installs a `developer` subagent (the implementation worker) for every assistant supporting file-based agents. It runs at the **balanced** tier by default — Sonnet on Anthropic tools, the provider's mid model elsewhere — and never the cheapest `light` model, which is too weak to build with. Offer once, in one line: > *"La implementación la hará un sub-agente `developer`. ¿Qué modelo? **balanced / Sonnet** (rápido y > económico — recomendado) o **heavy / Opus** (máxima calidad, más caro)."* Record to `.rsc/developer.json` and re-run install/sync so the agent files adopt it. Skipped → `balanced`, which install also writes by default. **Opt-out.** A fresh session auto-starts `init` while `user-profile.md` is absent. If the user does not want a harness in this repo, write an empty `.rsc/.no-harness` — that silences the auto-start permanently, even before a profile exists. Completing first contact silences it too. Commit the marker so the decision is shared by the team. ## Significant decisions: requirements first, then exactly three options For **any** significant decision — deploy target, database, framework, hosting, which CRM, where documents live — never decide silently and never dump ten options. 1. **Gather the requirements that actually drive the choice.** For a deploy target: expected users, concurrency, budget, data residency, the team's comfort operating servers, scaling needs. Ask only the ones that change the choice. 2. **Present exactly three options** with honest trade-offs: what each is good at, what it costs, what it demands of them. 3. **Recommend one**, matched to their answers, and say why in their register. 4. **Log it** to `decisions.md` once they pick. Canonical deploy example — Hetzner VPS + Coolify (cheapest, total control, you self-manage), Vercel (zero-ops, scales itself, expensive at scale), and a third matched to the case (Fly.io, Railway, or a managed cloud when compliance demands it). Requirements checklists per decision type and the worked example → `references/recommend-skills.md`. ## The flow ```text PROFILE → DISCOVER → INSTALL → GROUND → HANDOFF ``` ### Phase 1 — PROFILE Steps 1-2 above. Do not proceed until `user-profile.md` exists and `CLAUDE.md` links it. The framing of every later question depends on it, which is why it cannot wait until after discovery. ### Phase 2 — DISCOVER Establish **the state of the ground** and **what they want**. Detect greenfield vs brownfield; don't ask blindly. **Brownfield** if the workspace has subproject manifests (`package.json`, `pyproject.toml`, `pubspec.yaml`, `go.mod`, `Cargo.toml`), source files, legacy `XX-*` folders, or an existing `01-TOOLS/` / `02-DOCS/`. Detect the stack the way `harness` SCAN does — a read-only walk ignoring `node_modules/`, `.venv/`, `.next/`, `.git/`, `dist/`, `build/`, `__pycache__/`, `.dart_tool/`. Summarize what you found and confirm it. **Greenfield** if the workspace is empty or holds only stray notes: interview from zero. Then the domain. Software (backend, frontend, mobile, agents) or a non-code harness (company/ops, research, knowledge, content)? Capture goals, audience, constraints, and any tools already in play. Record to `02-DOCS/wiki/harness/` as you go. Questionnaires for both cases → `references/discovery.md`. Ask in short batches; never dump every question at once. ### Phase 3 — INSTALL Map what you learned to skills. **You have a terminal — install them yourself** after a one-word confirm: `npx @ericrisco/rsc add <ids>`. Only if you genuinely cannot run a shell, hand the exact command over for another tab. Never install without the confirm; it changes their environment. | Need | Skills | | --- | --- | | Always | `harness` — the control plane that scaffolds and governs the workspace | | Software backend | `fastapi` / `go`, `postgresdb` | | Software frontend | `nextjs` / `flutter`, `design` | | Marketing / landing / decks / teaching | `marketing`, `presentations`, `course-storytelling` | | AI agents | `building-agents` | | Shipping, security, wiring external tools | `secure-coding`, `deployment` | Show the shortlist with a one-line *why* per skill in their language, confirm, install. Recommend only what discovery justified — no "you'll probably want agents too". Then flag activation, 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."* Full skill map and sample printouts → `references/recommend-skills.md`. ### Phase 4 — GROUND Five checks once the skills are in. The SessionStart hook nudges each of these too; doing them here means the user starts clean. 1. **Version control.** No `.git/` → offer `git init`; the SDD chain and the ship guard assume it. Declined → write `.rsc/.no-git` so neither you nor the hook asks again, and log the decision. 2. **Context7 (live library docs).** For software, offer to wire it once: `claude mcp add --transport http context7 https://mcp.context7.com/mcp`. It gives version-correct docs instead of guessing from memory. Declined → `.rsc/.no-context7`. 3. **Skill audit.** Run `npx @ericrisco/rsc audit`. It inventories what is installed here and on the machine and flags overlap or skills with no footprint, so the project starts with the right set rather than a pile. Summarize it in their register. 4. **Tell them about the danger guard.** A `technical_level` of `non-technical` or `mixed` (and the state before any profile exists) turns on a `PreToolUse` guard that blocks irreversible commands — `rm -rf`, `git push --force`, `git reset --hard`, `DROP`/`TRUNCATE`, `DELETE`/`UPDATE` with no `WHERE`, `dd` to a device, `curl | bash` — and asks for a safer alternative. A fully `technical` user is never guarded. It turns off only if the user explicitly asks: `.rsc/.no-danger-guard`. Mention it when you record `non-technical`, so a later block is not a surprise. 5. **Automatic updates.** Ask once, yes by default: > *"Cuando salga una versión nueva de rsc, ¿la instalo sola? Las que cambian mucho (major) te las > preguntaré siempre. (sí/no)"* > *"When a new rsc version comes out, should I install it on my own? Big ones (major) I will > always ask about. (yes/no)"* Yes, or no clear answer → do nothing; it is on. No → create `.rsc/.no-auto-update`: every release then asks. It is a project switch, recorded in `.rsc.json` on the next sync. ### Phase 5 — HANDOFF The profile is set, the discovery recorded, the skills installed. What is missing is the workspace itself, and this is where onboarding used to end with a request: *"now run `harness`"*. Nothing ran it. Finishing depended on the user reading a line and typing something — and in a chat install that user has just delegated precisely so they would not have to know what to type. So **invoke `harness` yourself, now**, as the last step of this phase. Say what you are doing in one line, then do it: > "Tu perfil y lo que hemos hablado ya están guardados. Monto ahora el esqueleto del proyecto > (`01-TOOLS/` + `02-DOCS/`) leyendo todo lo que acabamos de decidir." `harness` still owns *how* the scaffold is built — you are calling it, not reimplementing it. Do not hand-roll directories here. **And if it does not happen, say so.** If `harness` cannot run, or stops half-way, **do not tell the user rsc is ready**: name what is missing and what will create it. The installer holds the same rule — it prints `RSC_ONBOARDING_INCOMPLETE` instead of `RSC_ONBOARDING_READY` when the harness floor is absent — and an agent that contradicts its own installer is worse than either alone. Claiming a harness that is not there is the one failure the user cannot diagnose, because everything looks installed and nothing behaves as if it were. ## Project grounding `init`'s record is the profile plus the append-only decisions log, both written in Phase 1 and updated throughout, and both kept in the short `## Knowledge map` pointer because they are the read-first entries. `scripts/verify.sh` checks the profile and the link exist (read-only; warns, never fails). ## See Also - `harness` — the scaffolder this hands off to; builds `01-TOOLS/` + `02-DOCS/` from the profile. - `deployment` — invoked when the deploy decision above is actually made. - `secure-coding` — recommended whenever software is being shipped. - Stack skills (`fastapi`, `go`, `nextjs`, `flutter`, `building-agents`…) are recommended at runtime by Phase 3 from discovery, never hardwired here. - References: `references/accompaniment-and-profile.md`, `references/discovery.md`, `references/recommend-skills.md`. ## Orientación (siempre) 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?".)