Repo scaffold

Skill majiayu000/spellbook/skills/repo-scaffold

Scaffold or standardize a production-ready repository structure with specs, source layout, tests, CI, agent context, config examples, release notes, and operational docs. Use when starting a new repo, turning a prototype into a maintainable project, adding missing repository foundations, or creating a repo skeleton before implementation. For AGENTS.md-only context scaffolding, use agentsmd-scaffold.From its SKILL.md

Install

npx -y skills add majiayu000/spellbook --skill repo-scaffold

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

SKILL.md

2.5 KB, 526 tokens by cl100k_base, as published. Nobody here has run it

Repo Scaffold

Purpose

Use this skill to create the repo foundation that lets product, architecture, implementation, verification, and operations stay connected. It is broader than agentsmd-scaffold; it may include AGENTS.md, but also specs, tests, CI, config, release, and runbook structure.

Search First

Before adding files, inspect the repo for existing equivalents:

rg --files -g 'AGENTS.md' -g 'CONTRIBUTING.md' -g 'README*' -g 'pyproject.toml' -g 'package.json' -g 'go.mod' -g 'Cargo.toml' -g '.github/workflows/*' -g 'docs/**' -g 'specs/**' -g 'tests/**'

Reuse existing conventions. Do not create parallel docs/, spec/, planning/, or test/ trees when the repo already has a standard location.

Scaffold Layers

Add only the layers needed for the repo:

Layer	Typical Files
Product and specs	`specs/PRODUCT.md`, `specs/TECH.md`, `docs/adr/`
Agent context	`AGENTS.md`, scoped `AGENTS.md`, local skill notes
Source layout	language-specific `src/`, `pkg/`, `cmd/`, `app/`, `lib/`
Tests	`tests/`, fixtures, golden snapshots, e2e harness
CI	`.github/workflows/ci.yml`, lint/typecheck/test jobs
Config	`.env.example`, config schema, secret inventory
Release	`CHANGELOG.md`, release checklist, versioning notes
Operations	`docs/runbooks/`, SLO and incident templates

Decision Rules

For a new repo, propose the tree first, then create files only after the user asks to apply.
For an existing repo, make the smallest additive change that closes the foundation gap.
Keep generated starter files short and executable. Prefer empty placeholders only when a tool requires them.
Do not hardcode credentials, service names, ports, or cloud providers without repo evidence.
Do not overwrite existing README, CI, or config files without showing the diff intent.

Minimal Output

For planning:

existing_foundation:
missing_layers:
proposed_tree:
files_to_create_or_update:
verification_commands:

For implementation, finish by running the repo's validation command and, when available, the scaffold-specific lint or generated-file check.

What ships with it: 1 file

240 B alongside SKILL.md

agents/

openai.yaml240 B

Gives 0 of the 12 instructions most project setup skills give in 526 tokens

Counted across 1,553 of the 3,091 authors here whose files we hold, read 2026-09-06

Write the configuration filein 36 of 1553
Create the directory structurein 35 of 1553, across 33 files
Verify the setupin 31 of 1553, across 28 files
Run the setup scriptin 30 of 1553, across 29 files
Pre-determine the required sample sizein 29 of 1553, across 12 files
Check if the configuration already existsin 29 of 1553
Document every testin 26 of 1553, across 10 files
Start with a hypothesisin 26 of 1553, across 11 files
Ask one question at a timein 22 of 1553
Test a single variable per testin 21 of 1553, across 9 files
Read product marketing context before asking questionsin 19 of 1553, across 8 files
Do not peek and stop earlyin 18 of 1553, across 7 files

Said here and by no other author read

Inspect the repo for existing equivalents before adding files
Reuse existing conventions
Add only the layers needed for the repo
Propose the tree first for a new repo
Make the smallest additive change that closes the foundation gap for existing repos
Keep generated starter files short and executable

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.