← ClaudeAtlas

scaffoldlisted

Generate GRACE-marked module skeletons from the plan and contract, so the implementer gets a code few-shot instead of a spec. Writes MODULE_CONTRACT, FUNCTION_CONTRACT, typed signatures, START_BLOCK anchors, block-anchored logs and IMPL directives; leaves block bodies unimplemented. Runs with the reasoning_high binding between /to-issues and the build cycle. Use for greenfield features, not bugfixes.
createusernam/setup_project · ★ 0 · AI & Automation · score 68
Install: claude install-skill createusernam/setup_project
# /scaffold — the handoff to the implementer is code, not a spec ## Why this skill exists The obvious way to drive a cheap implementer model is: strong model writes a spec, cheap model reads the spec and writes the code. It is also the wrong way, for two measured reasons: 1. **A spec costs about what the code costs.** A verbose strong model spends roughly 80% of the target code's token count writing the spec for it. You paid a high-reasoning model to *describe* the work, and you still have to pay to have it done. 2. **A spec is a weak prior; code is a strong one.** In-context learning is imitation. Give a model a prose spec and it composes from general priors. Give it a half-written module — real imports, real types, contracts, log anchors, named blocks — and it is a few-shot example: the model continues *in the same style*, inside boundaries it can see. Base training (FIM) taught these models to lean on code, not on documentation. Contracts embedded in the code are the one form of intent they cannot route around. So the strong model writes the **skeleton**: every boundary, signature, contract, block and log anchor — and no business logic. The cheap model fills the block bodies. Most of the token spend, and all of the routine work, moves down-tier. The GRACE Lite markup gets written by the model that is actually good at it, rather than being demanded from the weakest link in the chain. ## Where this fits ``` /contract → /judge → VIZ gate → /to-issue