scaffold
Skill187 starsChanged 5 months agoMITView on GitHub
Use to materialize the greenfield skeleton that survey's foundation session planned. Reads docs/architecture-map.md (mode: greenfield-bootstrap) plus docs/features/_scaffold/tasks.json and builds the real project structure: folders + entry point, test harness + smoke test, migration tooling, CI, the conventions doc. Triggers on "scaffold the skeleton", "materialize the skeleton", "bootstrap the project skeleton", "/sdd:scaffold", "матеріалізуй скелет", "розгорни скелет проєкту", "збудуй каркас". Runs the S-tasks sequentially inline (no team/workflow orchestration), anchored on the skeleton smoke test — builds + boots + empty test suite runs + migration tool runs — commits, and hands off to /sdd:specify. Hard-refuses without the greenfield foundation: run survey first.
49 other projects use a version of this.
Adopted by
Most recently taken up by
- mikeparcewski/wicked-gardentheir own version, first seen Nov 8, 2026
- codewithmukesh/dotnet-claude-kittheir own version, first seen Nov 8, 2026
- DnsQueen/orcinus-skillstheir own version, first seen Nov 8, 2026
- jurij/skillstheir own version, first seen Nov 8, 2026
- howells/scaffoldtheir own version, first seen Nov 6, 2026
- SethGammon/Citadeltheir own version, first seen Nov 4, 2026
Used with
Projects with it also use ascii-diagram, docs-ci and 10 more.
Other files people use alongside this one.
Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
SethGammonSkillascii-diagram
Generate perfectly aligned ASCII diagrams — architecture, flow, sequence, box-and-arrow. Uses a programmatic character-grid approach so alignment is guaranteed by math, not token prediction. Includes post-render verification.
Also in 4 projects that use this
jh941213Skilldocs-ci
문서 CI(링크·OpenAPI lint·breaking 게이트·mermaid 검증)나 문서 드리프트 감지(docs.yaml 신선도 검사)를 설치하거나 돌릴 때 사용. 문서 내용 작성은 docs-architecture·docs-interfaces·docs-manuals.
Also in 3 projects that use this
jh941213Skilldocs-interfaces
API·이벤트 인터페이스 문서(OpenAPI·swagger·AsyncAPI 명세, 엔드포인트 레퍼런스, API 구성도·시퀀스, API CHANGELOG)를 만들거나 코드와 맞출 때 사용. 시스템 구성도는 docs-architecture, API 설계 원칙은 api-design-principles.
Also in 3 projects that use this
SethGammonSkillresearch-fleet
Parallel research using Fleet wave mechanics. Spawns multiple scout agents, each investigating a different angle of the same question. Findings are compressed between waves. Produces a unified research brief from multiple independent perspectives.
Also in 3 projects that use this
RachaelQuiselSkillclient-docs
Client documentation. Use when a build needs documentation updates or missing project documents need to be identified.
Also in 3 projects that use this
vicoa-aiSkilllive-preview
Start a local app in the current user project, expose it through a tunnel, and return preview details in structured Markdown. Use when the user asks for a preview URL, public URL, shareable localhost, mobile/web preview, or tunnel setup.
Also in 4 projects that use this
- +4 more from jh941213
Other versions49 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 49
- SethGammon/Citadel★ 927same name
- codewithmukesh/dotnet-claude-kit★ 808same name
- me2resh/apexyard★ 542same name
- team-attention/hoyeon★ 173same name
- ambient-code/platform★ 131same name
- jh941213/ADLC-harness★ 125same name
- jh941213/my-cc-harness★ 125same name
- jh941213/my-claude-code-asset★ 125same name
- simota/agent-skills★ 96same name
- rust-off-rails/rustoffrails★ 49same name
39 more not listed
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository22 other files it gives its agents.
- apiSkill
- clarifySkill
- classify-sizeSkill
- configSkill
- data-modelSkill
- decide-adrSkill
- designSkill
- design-systemSkill
- fixSkill
- glossarySkill
- implementSkill
- interviewSkill
- plan-testsSkill
- reviewSkill
- roadmapSkill
- screensSkill
- sequencesSkill
- shipSkill
- specifySkill
- surveySkill
- tasksSkill
- ux-flowsSkill
The file
We split this skill into the rules it gives an agent
4 rules. 0 are common, 1 is distinctive, and 3 are very specific to this project.
0
Common
Most of the 42 edited versions we read keep these.
1
Distinctive
This author's own choices. Worth a look.
3
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 69
Drive the smoke test green: Write the smoke test as part of the harness task, then run the full anchor with the map's machine-key commands: …
- Very specific: line 72
Reconcile the map's machine keys: If the commands that actually worked differ from the map's frontmatter (build_cmd / test_cmd / lint_cmd / …
- Very specific: line 93
Every S-task from docs/features/_scaffold/tasks.json is materialized (or explicitly dropped with a reason), to the conventions the map …
- Very specific: line 101
Orchestrating five structural tasks: No team mode, no Workflow, no DAG engine — _scaffold is repo-level bootstrap, not a feature.
“Common” is measured: kept by at least 6 in 10 of the 42 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Skill: scaffold
The materialization step between survey's greenfield foundation and the first feature. survey
fixes the foundation (stack / structure / conventions in docs/architecture-map.md, marked
mode: greenfield-bootstrap) and emits the scaffold plan (docs/features/_scaffold/tasks.json,
tasks S1–S5 per ../survey/references/foundation.md);
scaffold turns that plan into a repo that builds, boots, tests and migrates — then the normal
per-feature flow (specify → … → implement) builds into it. This skill exists so the greenfield
handoff is a real gate, not a wave of the hand: _scaffold is not a feature (no .size, no
.route, no ACs), so it never enters implement's engine or its team/workflow decision tree.
The skeleton smoke test is the TDD anchor (canonical here). Scaffold tasks have no feature ACs, so red→green anchors on the structural smoke test: RED = the project does not build / boot / the tooling doesn't run; GREEN = build + boot + the empty test suite + the migration tool all succeed. That keeps the discipline meaningful for structural work — no per-folder TDD theatre.
Owner
Architect / Tech Lead — the same person who fixed the foundation in survey.
Inputs
docs/architecture-map.mdwithmode: greenfield-bootstrap— the decided stack, module structure, conventions, and the machine keys (build_cmd,test_cmd,lint_cmd,migration_tool,frontend).docs/features/_scaffold/tasks.json— the S1–S5 scaffold plan (layer: scaffold,slug: "_scaffold").
Protocol
- Hard gate. Both inputs must exist:
docs/architecture-map.mdwhose frontmatter saysmode: greenfield-bootstrap, ANDdocs/features/_scaffold/tasks.jsonparsing as the scaffold contract (slug: "_scaffold",layer: scaffoldtasks withid/title/deps/dod/files_hint). Either missing → refuse: «runsurveyfirst — its greenfield session fixes the foundation and emits the scaffold plan». A map without the greenfield marker means the repo is already real — refuse too and point at/sdd:specify <slug>. If the skeleton already exists (every S-task's output present and the smoke test green), say so and STOP — nothing to materialize. - Ensure the settings file (first thing, after this skill's own gate). If
.claude/sdd.local.mdis absent, create it now from the canonical template — documented defaults + the self-documenting body — and patch.gitignore; if it exists, read it and never overwrite. The one procedure lives in../_shared/settings-file.md. Creating is unconditional; changing values is only ever offered byconfig. Say one line: «.claude/sdd.local.mdcreated with documented defaults —/sdd:configto tune it». Then read the foundation. From the map: stack, folder/module structure, conventions catalog, the machine keys. Fromtasks.json: the S-tasks in dependency order. The map is the only source of decisions — scaffold never re-litigates stack/style choices (that wassurvey's session). - Materialize sequentially inline. Execute the S-tasks one by one in dependency order, in this
session — deliberately no agent team, no Workflow, no
implementdecision tree:_scaffoldhas no.size/.route, and five structural tasks need no orchestration. Per task: create the files itsfiles_hintnames, to the map's conventions; verify itsdod; record it done. A task that genuinely doesn't apply (e.g. no datastore → the migration task) is explicitly dropped with a stated reason — never silently skipped. - Drive the smoke test green. Write the smoke test as part of the harness task, then run the full anchor with the map's machine-key commands: build + boot + the empty test suite + the migration tool (apply + revert). Iterate until GREEN — a red skeleton is not done.
- Reconcile the map's machine keys. If the commands that actually worked differ from the map's
frontmatter (
build_cmd/test_cmd/lint_cmd/migration_tool), update the map —implement's command-detection cascade reads these keys; stale keys poison every later feature. - Structural self-check — per
../_shared/self-check.md, before any commit: verify 4 items: (1) the smoke test was actually executed and is green (build + boot + empty suite + migration tool — command output in hand, not assumed); (2) every S-task is done or explicitly dropped with a reason; (3) the map's machine keys match the commands that just ran (updated if they diverged); (4) every file the S-tasks'files_hintnames exists on disk and is not gitignored. Fix + re-check ≤2 cycles; surface anything unresolved — an unresolved item means no commits. - Commit per
../_shared/write-and-commit.md— the skeleton is one indivisible commit (scaffold: materialize skeleton, paths = the materialized files + the settings.gitignorepatch); the map, if step 5 changed it, is a separate commit (scaffold: architecture-map.md machine keys). - Handoff. Emit the stage-handoff block per
../_shared/handoff.md— What I did (tasks materialized, smoke-test result, «self-check: 4/4 pass», the commits with short SHAs) + Review before continuing (the committed skeleton diff +docs/architecture-map.md) + Run next:/clear, then/sdd:specify <slug>— the first real feature, with a real repo to build into.
Definition of Done
- Every S-task from
docs/features/_scaffold/tasks.jsonis materialized (or explicitly dropped with a reason), to the conventions the map fixes. - The skeleton smoke test is green: the project builds, boots, the empty test suite runs, the migration tool applies + reverts.
- The map's machine keys reflect the commands that actually work; the skeleton is committed.
Anti-patterns
- Orchestrating five structural tasks. No team mode, no Workflow, no DAG engine —
_scaffoldis repo-level bootstrap, not a feature; sequential inline is the design, not a fallback. - Per-folder TDD theatre. The smoke test is the one anchor; writing a failing test per directory is ceremony without information.
- Re-deciding the foundation. Stack/structure/convention choices live in the map + its ADRs
(
survey's session); scaffold materializes, it never re-litigates. A gap in the map goes back tosurvey, not into an improvised decision here. - Handing off red. «Skeleton written but doesn't boot» is not done — GREEN is the exit condition.
- Treating
_scaffoldas a feature. No.size/.route, no spec, no ACs — it never enters the per-feature pipeline or its size/route machinery.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

