agentleFS
genkovichgenkovich/sdd/skills/scaffold/SKILL.md

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

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.
  • SethGammonSkill

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

  • jh941213Skill

    docs-ci

    문서 CI(링크·OpenAPI lint·breaking 게이트·mermaid 검증)나 문서 드리프트 감지(docs.yaml 신선도 검사)를 설치하거나 돌릴 때 사용. 문서 내용 작성은 docs-architecture·docs-interfaces·docs-manuals.

    Also in 3 projects that use this

  • jh941213Skill

    docs-interfaces

    API·이벤트 인터페이스 문서(OpenAPI·swagger·AsyncAPI 명세, 엔드포인트 레퍼런스, API 구성도·시퀀스, API CHANGELOG)를 만들거나 코드와 맞출 때 사용. 시스템 구성도는 docs-architecture, API 설계 원칙은 api-design-principles.

    Also in 3 projects that use this

  • SethGammonSkill

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

  • RachaelQuiselSkill

    client-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-aiSkill

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

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
  1. Distinctive:

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

    line 69
  2. Very specific:

    Reconcile the map's machine keys: If the commands that actually worked differ from the map's frontmatter (build_cmd / test_cmd / lint_cmd / …

    line 72
  3. Very specific:

    Every S-task from docs/features/_scaffold/tasks.json is materialized (or explicitly dropped with a reason), to the conventions the map …

    line 93
  4. Very specific:

    Orchestrating five structural tasks: No team mode, no Workflow, no DAG engine — _scaffold is repo-level bootstrap, not a feature.

    line 101

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

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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.md with mode: 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

  1. Hard gate. Both inputs must exist: docs/architecture-map.md whose frontmatter says mode: greenfield-bootstrap, AND docs/features/_scaffold/tasks.json parsing as the scaffold contract (slug: "_scaffold", layer: scaffold tasks with id/title/deps/dod/files_hint). Either missing → refuse: «run survey first — 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.
  2. Ensure the settings file (first thing, after this skill's own gate). If .claude/sdd.local.md is 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 by config. Say one line: «.claude/sdd.local.md created with documented defaults — /sdd:config to tune it». Then read the foundation. From the map: stack, folder/module structure, conventions catalog, the machine keys. From tasks.json: the S-tasks in dependency order. The map is the only source of decisions — scaffold never re-litigates stack/style choices (that was survey's session).
  3. Materialize sequentially inline. Execute the S-tasks one by one in dependency order, in this session — deliberately no agent team, no Workflow, no implement decision tree: _scaffold has no .size/.route, and five structural tasks need no orchestration. Per task: create the files its files_hint names, to the map's conventions; verify its dod; 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.
  4. 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.
  5. 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.
  6. 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_hint names exists on disk and is not gitignored. Fix + re-check ≤2 cycles; surface anything unresolved — an unresolved item means no commits.
  7. Commit per ../_shared/write-and-commit.md — the skeleton is one indivisible commit (scaffold: materialize skeleton, paths = the materialized files + the settings .gitignore patch); the map, if step 5 changed it, is a separate commit (scaffold: architecture-map.md machine keys).
  8. 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.json is 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 — _scaffold is 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 to survey, not into an improvised decision here.
  • Handing off red. «Skeleton written but doesn't boot» is not done — GREEN is the exit condition.
  • Treating _scaffold as a feature. No .size/.route, no spec, no ACs — it never enters the per-feature pipeline or its size/route machinery.

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.