Init Agent Skill

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: two values, set before anything else

The whole harness behaves differently depending on these two. Nothing — no discovery, no

recommendation — happens before the profile exists and CLAUDE.md links it.

Step 1 — Gauge technical level. Literally the first thing you say, before any discovery, framed

so nobody feels small. Ask once, in their language:

> "Antes de nada, para hablarte como te resulte más cómodo: ¿te manejas con código y términos

> técnicos, o prefieres que te lo explique todo en cristiano? No hay respuesta mala — solo me ayuda

> a no aburrirte ni perderte."

> "First, so I talk to you the right way: are you comfortable with code and technical terms, or

> would you rather I explain everything in plain language? There's no wrong answer — it just helps

> me not bore you or lose you."

Record technical_level: non-technical | mixed | technical. Until they say otherwise, assume

non-technical: plain language, analogies over acronyms.

Step 2 — Set the accompaniment dial. Present it and let them pick; describe the options, do not

just list letters.

| Level | What they get |

| --- | --- |

| L0 — cavernícola | Results, almost no explanation. One line of output; no questions beyond hard blockers. |

| L1 — breve | One line of *why* per step; questions only when genuinely ambiguous. |

| L2 — explica decisiones | Each relevant decision justified; asks before each significant one. |

| L3 — acompañamiento total | Explains everything, reasons out loud, asks a lot. Ideal for learning while building. |

Non-technical and silent → default L3. Technical and silent → L1. technical_level is an

orthogonal modifier: even at L0 a non-technical user gets plain phrasing; even at L3 a technical one

skips the 101s. Every rsc skill reads these two values and obeys them — L0 means *do it and stop

talking*. Full rules and file formats → references/accompaniment-and-profile.md.

Step 3 — Persist immediately. Before discovery, before any recommendation:

• 02-DOCS/wiki/harness/user-profile.md — the living profile (levels, 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 4 — 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, calibrated to the dial:

> *"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 (e.g.

at L0) → 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.

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

the number of questions to the dial.

• Present exactly three options with honest trade-offs: what each is good at, what it costs,

what it demands of them.

• Recommend one, matched to their answers and their level, and say why in language they follow.
• 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-3 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 batches sized to the dial; 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

Four checks once the skills are in. The SessionStart hook nudges each of these too; doing them here

means the user starts clean.

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

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

• 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 at their level.

• 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 set a non-technical level, so a later block is not a surprise.

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)

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.