scaffold-pack-authorlisted

Author an in-tree scaffold-toolkit template pack for the repo you are in — any language, any architecture. Asks whether the repo intends to migrate toward a different target architecture (author a second, additive pack if so) and splits out external/infra packages (cloud SDKs, message brokers, secret managers) into their own packs. Study the repo's recurring pattern, turn one real instance into a versioned pack (Handlebars templates + descriptor + AI_IMPLEMENTATION markers + registry injections + test_data + a real build-check), wire the markers into the existing brownfield files, and point `.scaffold/config.json` at it so the pack lives in the repo's own git tree and the team maintains its coding standards there. Use when the user says "author/create a scaffold pack", "make a pack for this repo", "cut a new pack version", or "wire scaffold into this codebase". This is the producer side; the `scaffold` skill is the consumer side that runs `generate`.
MohanTn/mohan-dotfiles · ★ 1 · Data & Documents · score 64

Install: claude install-skill MohanTn/mohan-dotfiles

# scaffold-pack-author — author an in-tree template pack for this repo You are the **producer** side of `scaffold-toolkit`. The `scaffold` skill *consumes* a pack (runs `generate`). This skill *creates* the pack the team will consume, living **inside the target repo's git tree** so coding standards are versioned and maintained in the same codebase. The CLI (`@mohantn/scaffold-core`, binary `scaffold`) is LLM-agnostic and deterministic: it renders Handlebars templates and injects marker-delimited boilerplate. It never calls a model. Your job is the probabilistic half the CLI cannot do: 1. **Read this repo** and find the one recurring unit that follows a pattern (a controller+service+DTO+DI registration, a NestJS/feature module, a React feature + route + barrel export, a Go handler + wire.go entry, …). 2. **Factor that unit** into: fixed boilerplate → `.hbs` templates; variable parts → `inputs`/`{{placeholders}}`; wiring/registration points → **injection markers**; logic-only bodies → **`AI_IMPLEMENTATION` markers**. 3. **Author the pack** (descriptor + templates + `test_data` + a real build-check), **validate** it, **adopt** it into the brownfield repo (init + bootstrap markers), and hand off to the `scaffold` consumer skill. Everything you author is committed to the repo. A future `scaffold generate` run must produce byte-identical output from the same manifest — determinism is the whole point, so no nondeterministic template logic (timestamps, random ids, unordered maps)