Repo scaffold

Skill majiayu000/spellbook/skills/repo-scaffold

Cross-runtime skills for Claude Code, Codex, and multi-agent workflows.

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.

What its author says it does

Copied from the file, not written here

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.

SKILL.md

2.5 KB, 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.