Use when calibrating an existing repo for the rsc SDD chain: detect stack, package manager, test runners and apply/verify commands, refresh the skill registry, and write the runtime config at 02-DOCS/wiki/sdd/config.yaml. NOT the dispatcher that routes SDD phases (that is `sdd`), NOT first-contact user/workspace bootstrap (that is `init`).
Scanned 9/2/2026
Install to Claude Code
npx -y skills add ericrisco/rsc-harness --skill sdd-init --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Sdd Init?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/ericrisco-sdd-init)More formats (shields.io, HTML) on the badges page.
---
name: sdd-init
description: "Use when calibrating an existing repo for the rsc SDD chain: detect stack, package manager, test runners and apply/verify commands, refresh the skill registry, and write the runtime config at 02-DOCS/wiki/sdd/config.yaml. NOT the dispatcher that routes SDD phases (that is `sdd`), NOT first-contact user/workspace bootstrap (that is `init`)."
tags: [sdd, init, config, testing, registry]
recommends: [sdd, specify, implement, verify]
profiles: [core, full]
origin: risco
---
# sdd-init — calibrate the repo before the SDD chain
Step zero for technical SDD work: read the repo, detect how it should be built and tested, refresh the cheap skill registry, and write one durable config:
```text
02-DOCS/wiki/sdd/config.yaml
```
That config is the runtime contract later phases read before choosing commands, TDD strictness, artifact paths, review budget or skill briefs. `sdd` dispatches the phases that consume it, `init` owns first contact and user profiling, `harness` owns `01-TOOLS/` and `02-DOCS/` scaffolding. This skill only calibrates.
## Inputs
Read-only first:
- `package.json`, lockfiles, `pnpm-workspace.yaml`, `pyproject.toml`, `requirements.txt`, `go.mod`, `pubspec.yaml`, `Dockerfile`, `.github/`.
- Existing `02-DOCS/wiki/sdd/config.yaml`, if present.
- `02-DOCS/wiki/harness/user-profile.md`, if present, for accompaniment level only.
- `.rsc/skill-registry.json`, if present, to decide whether it is stale or missing.
If `02-DOCS/` does not exist, create only the `02-DOCS/wiki/sdd/` path needed for the config. Do not run full harness scaffolding unless the user asked for `harness`.
## Preflight Choices
Ask only when the answer changes behavior; let the accompaniment level in the profile set how much you explain each trade-off.
| Setting | Default | Options |
| --- | --- | --- |
| `execution_mode` | `interactive` | `interactive` pauses at review-risk gates; `automatic` chains phases until a blocker/risk appears. |
| `artifact_store` | `02-DOCS/wiki/sdd` | Keep RSC artifacts in `02-DOCS`; do not create an `openspec/` parallel tree. |
| `review_budget.line_budget` | `400` | Lower for solo tight review; higher only with explicit approval. |
| `delivery_strategy.default` | `ask-on-risk` | `ask-on-risk`, `single-pr`, `autochain`, `exception`. |
| `models.enabled` | `false` | Per-phase model routing is opt-in; leave off unless the user asks for it. |
| `models.provider` | `anthropic` | Which provider the tiers resolve to. Set from the detected assistant when obvious, else `anthropic`. See `../sdd/references/model-routing.md` for other providers. |
## Detection
Use the repo detector exposed by the CLI code (`detectRepoProfile`) or reproduce the same facts manually if running inside an agent without code access:
- stacks: Next.js/React, FastAPI/Python, Go, Flutter, Postgres, deployment signals;
- package managers: pnpm, npm, yarn, bun;
- scripts: `test`, `lint`, `typecheck`, `build`;
- runners: Vitest, Jest, Playwright, pytest, `go test`, `flutter test`;
- monorepo signals;
- recommended apply and verify commands;
- the active assistant/provider when it's obvious from the environment (Claude Code, Codex, Gemini…), to seed `models.provider` — default `anthropic` when unsure. This only sets the *concrete model names*; routing itself stays off until the user opts in.
If any runner is detected, set `testing.strict_tdd: true`. Strict TDD means implement phases must do red -> green -> triangulate edge cases -> refactor, with command evidence. If no runner is detected, set it false and record the gap rather than pretending.
## Skill Registry
Refresh the project registry:
```bash
npx @ericrisco/rsc registry refresh
```
This writes:
```text
.rsc/skill-registry.json
.rsc/skill-registry.md
```
Later phases use it as a cheap index — id, trigger, tags, path, installed/available, hash — to select the few skills matching the phase and stack and digest them into compact rules for subagents.
## Equip the repo — install the skills this stack needs
Calibration is the moment to make sure the relevant skills are actually present, not just indexed. Detect → propose → install:
1. **Detect what this repo needs.** Use the stack you just detected, or ask the CLI: `npx @ericrisco/rsc consult "<one line: stack + what we're building>"`. Map signals to skills — e.g. `next`→`nextjs`+`design`, `go.mod`→`go`, FastAPI→`fastapi`, `*.sql`/Prisma→`postgresdb`/`prisma-orm`, Stripe→`stripe`, Dockerfile/CI→`docker`/`github-actions`, tests→`testing-*`/`e2e-testing`. The SDD phase skills (`specify`…`ship`) should already be present from `--profile core`; install any that are missing.
2. **Show the shortlist + confirm.** List the skills with a one-line *why* each, matched to the accompaniment dial, and get a one-word confirm before touching their environment.
3. **Install them yourself.** You have a terminal — run it via Bash:
```bash
npx @ericrisco/rsc add <skill> [<skill> ...]
```
If you genuinely cannot run a shell, print the exact command and ask the user to paste it in another terminal tab.
4. **Flag the new session.** Newly installed skills load at the START of a session. Tell the user: *"Instaladas. Abre una pestaña/sesión nueva de tu asistente (o recarga) en esta carpeta para que se activen."* Then refresh the registry again so `installed/available` is accurate.
## Config Shape
Write `02-DOCS/wiki/sdd/config.yaml` in this shape:
```yaml
version: 1
project:
root: .
stacks: []
package_managers: []
monorepo: false
signals: []
sdd:
artifact_store: 02-DOCS/wiki/sdd
execution_mode: interactive
registry_path: .rsc/skill-registry.json
review_budget:
line_budget: 400
file_budget: 12
delivery_strategy:
default: ask-on-risk
testing:
strict_tdd: false
runners: []
commands:
apply: []
verify: []
phase_rules:
proposal: optional-on-ambiguity
specify: requires intent or proposal
plan: requires spec
tasks: requires plan and spec
analyze: requires spec plan tasks
implement: requires analyze pass, strict_tdd when testing.strict_tdd is true
verify: requires spec tasks evidence
archive: requires verify record and review/ship outcome
models:
enabled: false # opt-in master switch; false = honor session model, announce nothing
provider: anthropic # which provider the tiers below resolve to
tiers:
heavy: claude-opus-4-8
balanced: claude-sonnet-4-6
light: claude-haiku-4-5-20251001
phases:
constitution: heavy
specify: balanced
clarify: balanced
plan: heavy
tasks: balanced
analyze: heavy
implement: balanced
verify: balanced
review: heavy
ship: light
debug: heavy
worktrees: light
sdd-init: light
overrides: {} # per-phase tier overrides set by the user
```
The `models` block is the **per-phase model routing** profile: each phase declares a tier (`heavy`/`balanced`/`light`) and the tiers resolve to concrete models for `provider`. The full protocol — how phases apply it, the per-assistant switch mechanism, the provider→model table — lives in `../sdd/references/model-routing.md`. Keep this block byte-for-byte in sync with that reference.
Preserve user edits if the file exists: update detected facts and leave comments/custom policy fields intact when possible. **Never flip `models.enabled` or drop `models.overrides` on re-calibration** — a calibration pass that silently switches the user's models is the one failure they cannot detect from the diff, so preserve both verbatim and only refresh `tiers`/`provider` if the user asks. If preservation is risky, write a proposed replacement next to it as `config.proposed.yaml` and ask.
## Result Envelope
End with the standard SDD result envelope:
```json result-envelope
{
"status": "complete",
"executive_summary": "SDD config calibrated and registry refreshed.",
"artifact": "02-DOCS/wiki/sdd/config.yaml",
"next_recommended": "sdd",
"risk": "low",
"skill_resolution": {
"used": ["sdd-init"],
"missing": [],
"fallback": [],
"compact_rules": [
"Read config.yaml before choosing commands.",
"Use .rsc/skill-registry.json as the cheap skill index.",
"Per-phase model routing ships off (models.enabled:false); never switch models unasked."
]
},
"evidence": ["npx @ericrisco/rsc registry refresh", "detected test commands recorded"]
}
```
## Anti-patterns
| Temptation | Reality |
| --- | --- |
| "I'll skip config and remember the commands in chat." | Chat is not source of truth. Write `config.yaml`. |
| "No test command detected, but I'll still say strict TDD is active." | Strict TDD needs a runner. Record the gap. |
| "Load all skills so the agent has context." | That pollutes context. Use registry -> selected skills -> compact rules. |
| "This is the same as init." | No. `init` profiles user/workspace, `sdd` dispatches the phases, `sdd-init` calibrates the technical SDD runtime they both rely on. |
| "Create openspec/ because Gentle does." | RSC uses `02-DOCS/wiki/sdd/` as source of truth. |
## Next
After `sdd-init`, return to `sdd`. If no spec exists, route to `specify`. If the work is ambiguous or architectural, write a proposal first under `02-DOCS/wiki/sdd/proposals/`.
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!