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

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?".)