Sdd Init

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:

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.

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:

npx @ericrisco/rsc registry refresh

This writes:

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

   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:

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:

{
  "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

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