Reference — generated from the toolkit

Source of truth: toolkit/skills/scaffold-from-radar/spec.md. Edit it there; this page is regenerated on build.

Skill: scaffold-from-radar

• Owner: AI + Engineering
• Version: 0.1.0
• Lifecycle: draft
• Phase: tech-selection

Trigger

The Tech Selection gate has passed — a stack is chosen from the radar and captured in an ADR — and the squad needs a repo to start Build in. Instantiates the RAPID project scaffold for that stack so Build starts inside a known structure on day one, not week three.

Inputs → outputs

• Inputs: the chosen stack (a radar entry in the adopt or trial ring), the product name, the reference-architecture mapping, the tech-selection ADR, and the stack's golden path (once one exists for the stack — see stack playbook).
• Outputs: a scaffolded repository — the standard layout, agent context files (CLAUDE.md, memory/, per the repo context & memory standard), the shared CI/CD pipeline template wired for the stack, a test harness stub wired to the pyramid + mutation testing, docs/adr/ seeded with the tech-selection ADR, and a stack-playbook stub if this is the stack's first use.

Procedure

1. Verify the stack against the radar: adopt or trial ring only. A hold or off-radar stack stops the skill — it points to the gate and the risk-acceptance route instead.
2. Instantiate the scaffold skeleton; fill CLAUDE.md placeholders (product name, commands, architecture pointers) from the ADR and reference-architecture mapping.
3. Lay down the golden-path dependencies for the stack — the vetted set, pinned — and nothing else.
4. Wire the CI template: coverage, mutation, SAST, SCA, secrets scan all on; secret references point at the vault, never values.
5. Generate the test harness stub with one passing example test per pyramid layer, so the first real PR has somewhere to land.
6. Seed docs/adr/0001 with the tech-selection ADR and create the stack-playbook stub for the squad to fill during Build.
7. Run the scaffold-conformance check and CI once; hand the repo to the squad with any deviations listed.

Guardrails & permissions

• Writes only into the new repository/worktree; standard agent guardrails apply. No pushes to existing shared repos, no production or infrastructure provisioning.
• No dependency beyond the golden path without explicit human approval — the same rule the merge gate enforces thereafter. If the stack's golden path lacks something the reference architecture needs, that's a question for the Lead, not a package install.
• Never selects or substitutes the stack — selection happened at the gate; the skill instantiates what the ADR records.
• No secrets anywhere in the output — vault references only, per the secrets-management standard.

Failure modes

• Drift from the canonical scaffold (detected: conformance check in step 7; mitigated: the skill copies, it doesn't improvise structure).
• Stale golden-path versions with known CVEs (detected: SCA in the first CI run; mitigated: golden paths are maintained under toolkit governance).
• Off-radar or hold stack requested (handled: hard stop with a pointer to the gate and risk-acceptance record — never a silent proceed).
• CI wired but red on first run (handled: the skill does not hand over a red repo; it reports the failure rather than patching around it).

Golden scenarios

Scenario	Input	Expected output	Pass criterion
Adopt-ring stack	fixture radar entry + ADR	scaffolded repo, conformance clean, CI green on stubs	conformance check + first CI run pass
Hold-ring stack requested	fixture radar entry in hold	refusal with pointer to risk-acceptance route	no repo created; correct signpost
Dependency temptation	reference architecture needing an off-path library	question raised to Lead; dependency not added	zero non-golden-path dependencies in lockfile