Agentify

Set up or upgrade a repo so any AI agent can work in it effectively. Use when the user says "agentify this repo", "make this repo agent-friendly", "set up AGENTS.md / CLAUDE.md", "add a decision log", "start a new project with the agent setup", or is scaffolding a greenfield project. Creates the canonical doc set (AGENTS.md + CLAUDE.md symlink, docs/architecture.md, docs/decisions.md, docs/lessons.md, docs/design.md), golden-path scripts (verify/run), and the maintenance contract that keeps them true.From its SKILL.md

Install

npx -y skills add AceyAdapter/knap --skill agentify

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

One thing to look at

1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

5.7 KB, as published. Nobody here has run it

Agentify a repo

Goal: after this skill runs, ANY agent — Claude Code, Codex, a small open model — can open the repo cold, read one file, and know what the project is, how to build/run/verify it, what's settled, and what not to touch. The reference implementation is Nick's next-up repo; this skill reproduces that pattern.

The artifact set

File	Job	Template
`AGENTS.md`	Canonical agent entry point, ≤150 lines. The map, not the territory.	`templates/AGENTS.template.md`
`CLAUDE.md`	Symlink to AGENTS.md (`ln -s AGENTS.md CLAUDE.md`). Never a copy.	—
`scripts/verify.sh`	One command that proves a change works: build + tests, loud ✅/❌ exit.	`templates/verify.template.sh`
`scripts/run.sh` (or `sim.sh`/`dev.sh`)	One command that launches the app for eyes-on checks (screenshot for UI projects).	project-specific
`docs/architecture.md`	File map with one-line annotations + data flow. The territory.	`templates/architecture.template.md`
`docs/decisions.md`	Append-only, dated D-numbered log of the WHY, with a supersession map at top.	`templates/decisions.template.md`
`docs/lessons.md`	Agent mistakes → corrections. Consulted before repeating a task class, appended when the human corrects the agent.	`templates/lessons.template.md`
`docs/design.md`	UI projects only: tokens, principles, motion. "Read before styling anything."	`templates/design.template.md`

Templates live next to this file in templates/. They are skeletons with inline guidance comments — fill them from reality, then delete the comments.

Mode 1 — existing repo (upgrade)

Derive everything from the repo before writing a word. Never invent commands or architecture — a doc that lies is worse than no doc.

Audit. Read README, package manifests (package.json / *.xcodeproj / pyproject.toml / go.mod …), CI config, existing scripts, and any existing CLAUDE.md/AGENTS.md content (fold it in, don't discard it). Map the top two directory levels. Run the build and test commands yourself to confirm they work and time them.
Golden-path scripts. Wrap the verified build+test incantation in scripts/verify.sh. Add a run/preview script if the project has a runnable surface. Loud output: end with ✅ verify passed or ❌ + a nonzero exit.
Write docs/architecture.md from the actual file tree — every non-obvious file gets a one-line annotation.
Seed docs/decisions.md. Interview the user for 3–8 already-settled decisions (framework choice, hard constraints, things they're tired of re-explaining) and backfill them as D1..Dn with today's date. Ask explicitly: "What do agents keep getting wrong or re-litigating here?" Those answers are D-entries or lessons.
Seed docs/lessons.md with any known agent failure modes from step 4.
Write AGENTS.md last, from the template — it summarizes what now exists. Symlink CLAUDE.md. If other agent files exist (.cursorrules, codex.md…), make them symlinks or one-line pointers to AGENTS.md too.
Verify: scripts/verify.sh passes; readlink CLAUDE.md → AGENTS.md; wc -l AGENTS.md ≤ 150; every command in the commands table was actually run this session.

Mode 2 — greenfield

Interview first, briefly: what's being built, target platform/stack, hard constraints (min OS, privacy rules, device support…), does it have UI.
Scaffold the project (stack-appropriate) so scripts/verify.sh has something real to build/test from day one — even if it's a hello-world with one test. Never commit a verify script that hasn't passed.
Create the full artifact set. docs/decisions.md starts with D1 = stack choice and one entry per constraint from the interview. State line says "scaffolding — nothing shipped."
For UI projects, seed docs/design.md before the first screen is built — pull candidate direction from the plugin's resources/design-inspiration.md and resources/tools.md (at ${CLAUDE_PLUGIN_ROOT}/resources/ when running as a plugin) and confirm a direction with the user.

The AGENTS.md rules (both modes)

≤150 lines. Detail belongs in docs/; AGENTS.md is the map.
Required sections, in order: intro paragraph (what this is + where deep dives live) · dated State line · Commands table with real measured runtimes · gotchas · What can be verified where · Hard constraints · Architecture in one breath · Maintenance contract · Scope discipline.
The maintenance contract is what keeps the system alive — always include it verbatim-ish from the template: verify before done, dated decision entries in the same change, docs updated in the change that invalidates them, state line kept current, lessons appended when corrected.

Style

Write docs in plain, dense prose — no filler, no marketing voice. Every command documented must have been executed. Assume the reader is a capable but context-free agent: golden paths, not options. When in doubt whether something is AGENTS.md-worthy or docs/-worthy: AGENTS.md gets what an agent needs every session; docs/ gets what it needs sometimes.