mcpbeat Sign in

Sdd Init Agent Skill

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`).

3k tokens
context cost
the whole folder, loaded on every use
3
files
instructions only
0
copies elsewhere
how many repositories repackaged it
105
stars on the repo
on the repository, not the skill itself

Install

one command, takes just this skill from the repository
npx skills add https://github.com/ericrisco/rsc-harness --skill sdd-init

What comes with it

2 750 bytes besides the instruction
evals/README.md
evals/cases.yaml

What it tells the agent to use

found in the instruction text
Task spawns other agents

The instruction itself

10 sections, as written by the author

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.

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

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:

  • 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. nextnextjs+design, go.modgo, FastAPI→fastapi, *.sql/Prisma→postgresdb/prisma-orm, Stripe→stripe, Dockerfile/CI→docker/github-actions, tests→testing-*/e2e-testing. The SDD phase skills (specifyship) should already be present from --profile core; install any that are missing.
  • 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.
  • 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.

  • 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

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

How to use it

Copy the folder

Take ericrisco/sdd-init from the repository into ~/.claude/skills for personal use, or into .claude/skills inside a project.

Check the name does not clash

The agent identifies a skill by the name field in its header. Two skills with the same name cannot sit side by side — one of them will be ignored.

Install what it needs

The instructions reference npx. Without those the skill loads but fails at the first command.