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.