agentic-repo-scaffold
Skill4 starsChanged 55 days agoMITView on GitHub
Scaffold a repo's agent-maintainability contract: AGENTS.md architecture contract + executable verify harness (boundary / giant-file / generated-clean checks) + a single `make verify` / `pnpm verify` + `.agent/` ledgers. Stack-aware. Use on "scaffold AGENTS.md", "set up the agent contract", "add a verification harness", "make this repo agent-maintainable", "wire up make verify", or starting/hardening a repo for long-horizon agent maintenance. Distinct from /init (docs CLAUDE.md): this writes the CONTRACT + executable gates.
In this repository39 other files it gives its agents.
- AGENTS.mdAGENTS.md
- agent-travel-plannerSkill
- ai-workflow-spineSkill
- ana-awardSkill
- analyze-video-evidenceSkill
- apple-pdfSkill
- audit-fix-loopSkill
- autonomous-grindSkill
- award-flightsSkill
- banxian-skillSkill
- big-taskSkill
- clean-room-rewriteSkill
- cloudflare-r2-setupSkill
- codebase-sweepSkill
- context-infrastructureSkill
- deep-researchSkill
- download-web-videoSkill
- dr-sharpSkill
- game-script-creationSkill
- gemini-imageSkill
- gpt-imageSkill
- investigateSkill
- jewelry-marketingSkill
- learning-coachSkill
- mineru-pdf-parserSkill
- mtcSkill
- narrative-researchSkill
- neat-freakSkill
- pet-forgeSkill
- plan-design-reviewSkill
- pr-fix-loopSkill
- proxy-node-setupSkill
- serenity-bottleneck-researchSkill
- task-shaped-agent-routingSkill
- transcribeSkill
- tridentSkill
- tui-engineeringSkill
- wandian-writerSkill
- web-novel-writingSkill
The file
We split this skill into the rules it gives an agent
8 rules. About 0 are common, 2 are distinctive, and 6 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈2
Distinctive · estimate
This author's own choices. Worth a look.
6
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 27
Create a todo per step.
- Very specific: line 30
Read package.json / go.mod / pyproject.toml / Cargo.toml, the build scripts, and the top-level tree.
- Very specific: line 41
If CLAUDE.md is absent, drop the thin pointer from templates/CLAUDE.pointer.md.
- Very specific: line 52
Use templates/Makefile.fragment or templates/package.verify.json as the starting shape.
- Very specific: line 55
Create .agent/PROGRESS.md, .agent/EVIDENCE.md, .agent/DECISIONS.md from templates/agent-ledgers/.
- Very specific: line 59
If the repo uses Cursor, drop the scoped .cursor/rules/*.mdc from the matching reference §8 (boundaries rule + verification rule).
- Very specific: line 62
If a CI workflow exists, add a job that runs the canonical verify command.
- Distinctive: line 65
Run each new check script and the verify command.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
agentic-repo-scaffold
Turns the agentic-repo-architecture framework into committed, executable artifacts in a target repo.
Core principle: instruction files are context, not enforcement. Every architecture rule this skill writes into AGENTS.md must have a matching deterministic check in tools/verify/ and CI, or it will be violated under context pressure.
When to use / not use
- Use for: a new repo, or hardening an existing one toward agent-safe boundaries; adding the verify harness; wiring
make verify; standing up.agent/ledgers for a long refactor. - Don't use for: writing a codebase-walkthrough doc (that's
/init), or a one-file change. This is repo-infrastructure scaffolding.
Procedure
Create a todo per step.
1. Detect stack and existing surface
- Read
package.json/go.mod/pyproject.toml/Cargo.toml, the build scripts, and the top-level tree. - Classify: frontend/full-stack (Next.js/React), backend/service (API/worker/RPC/events), or general (CLI/SDK/lib/monorepo/infra). Monorepo → classify per package.
- Inventory what already exists:
AGENTS.md,CLAUDE.md, anytools/verifyor check scripts,.agent/,.cursor/rules, averifycommand, CI workflow. Never clobber a richer existing file — extend it, or write a.proposedsibling and diff. - Load the matching stack reference (bundled in this skill) for the authoritative layer rules / contract tables / acceptance matrix:
- frontend →
references/frontend.md - backend →
references/backend.md - general →
references/general.md
- frontend →
2. Write AGENTS.md (the architecture contract)
- Start from
templates/AGENTS.template.md. Fill in: real architecture map (use the ACTUAL directory names in this repo — don't imposecore/application/ports/adaptersnames if the repo already has a working, legible convention; map the roles onto its real paths), import rules, contract rules, file limits, the verify command, and the done-definition. - Enrich the stack-specific sections (layer table, boundary rules, backend contract list) from the matching reference file's §6/§8. Keep it a routing map, not a knowledge dump — link to deeper docs rather than inlining them.
- If
CLAUDE.mdis absent, drop the thin pointer fromtemplates/CLAUDE.pointer.md. If it exists and is substantive, leave it; just ensure it referencesAGENTS.md.
3. Install the verification harness
- Copy from
templates/, adapting globs/paths to the repo:check-giant-files.mjs(language-agnostic LOC gate; orcheck-giant-files.pyfor non-JS repos)check-boundaries.mjs(forbidden-import / purity check — set the layer regexes to the repo's real paths)check-generated-clean.sh(regenerate +git diff --quiet; skip if the repo has no generated code)
- Wire ONE canonical command running the full gate set. Match the repo's runner:
- JS/TS → a
verifyscript inpackage.json(typecheck → lint → unit → contract → e2e/visual where present → architecture checks). - Go → a
make verifytarget (go vet→golangci-lint→go test ./...→ arch/giant-file checks). - Python →
make verify(ruff/mypy→pytest→ checks).
- JS/TS → a
- Use
templates/Makefile.fragmentortemplates/package.verify.jsonas the starting shape.
4. Stand up .agent/ ledgers (only for genuine long-horizon work)
- Create
.agent/PROGRESS.md,.agent/EVIDENCE.md,.agent/DECISIONS.mdfromtemplates/agent-ledgers/. - These are repo-committed ledgers for multi-session refactors — not session-handoff scratch files. Name them PROGRESS/EVIDENCE/DECISIONS, commit them, and skip this step for a fresh repo with no active long refactor.
5. Optional: Cursor rules
- If the repo uses Cursor, drop the scoped
.cursor/rules/*.mdcfrom the matching reference §8 (boundaries rule + verification rule). Skip otherwise.
6. Optional: CI gate
- If a CI workflow exists, add a job that runs the canonical verify command. If not, offer
templates/ci-verify.yml(GitHub Actions). A check that isn't in CI is advisory only.
7. Verify the harness actually runs
- Run each new check script and the verify command. They must execute (even if they report pre-existing violations — that's signal, surface it). A scaffold that doesn't run is not done.
- Report: what was created/extended, which checks pass vs. flag existing debt, and the exact
verifycommand. Do not mark done from inspection — show command output.
Notes
- Templates and the
references/blueprint ship inside this skill, so the package is self-contained. - Be surgical: in an existing repo, adapt to its conventions rather than imposing the reference's directory names. The roles (pure core, orchestration, ports, adapters, isolated generated, thin transport) are the invariant; the names are the repo's.
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.

