setup
Skill13 starsChanged 4 months agoMITView on GitHub
The one entry point for installing ADR Kit in a project (R19). Modes: register (default), adopt (audit + propose ADRs, /adr-kit:init), hooks (/adr-kit:install-hooks), upgrade (/adr-kit:upgrade).
191 other projects use a version of this.
Adopted by
Most recently taken up by
- hydra-db/hydradb-claude-codetheir own version, first seen Nov 8, 2026
- WALKERKILLER/Look-Tongji-Notestheir own version, first seen Nov 8, 2026
- steerlabs/opensteertheir own version, first seen Nov 8, 2026
- ansvisor/ansvisortheir own version, first seen Nov 8, 2026
- dsifry/metaswarmtheir own version, first seen Nov 8, 2026
- anombyte93/prd-taskmastertheir own version, first seen Nov 8, 2026
Used with
Projects with it also use add-voice-transcription, add-discord and 10 more.
Other files people use alongside this one.
Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
juancruzmunozalbeloSkilladd-voice-transcription
Add voice message transcription to NanoClaw using OpenAI's Whisper API. Automatically transcribes WhatsApp voice notes so the agent can read and respond to them.
Also in 5 projects that use this
MicrosoftSkilladd-discord
Add Discord bot channel integration via Chat SDK.
Also in 11 projects that use this
MicrosoftSkilladd-slack
Add Slack channel integration via Chat SDK.
Also in 11 projects that use this
juancruzmunozalbeloSkilladd-telegram-swarm
Add Agent Swarm (Teams) support to Telegram. Each subagent gets its own bot identity in the group. Requires Telegram channel to be set up first (use /add-telegram). Triggers on "agent swarm", "agent teams telegram", "telegram swarm", "bot pool".
Also in 7 projects that use this
- +8 more from microsoft
Other versions191 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 191
- anthropics/knowledge-work-plugins★ 35ksame name
- garrytan/gbrain★ 32ksame name
- gavrielc/nanoclaw★ 31ksame name
- nanocoai/nanoclaw★ 31ksame name
- qwibitai/nanoclaw★ 31ksame name
- Q00/ouroboros★ 6.3ksame name
- pytorch/executorch★ 5.2ksame name
- agenticnotetaking/arscontexta★ 3.5ksame name
- aws/agent-toolkit-for-aws★ 3.4ksame name
- spotify/portal-ai-plugins★ 2.8ksame name
181 more not listed
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository19 other files it gives its agents.
The file
We split this skill into the rules it gives an agent
9 rules. 0 are common, 3 are distinctive, and 6 are very specific to this project.
0
Common
Most of the 170 edited versions we read keep these.
3
Distinctive
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
- Very specific: line 30
Write the project's instruction layout with scripts/setup-project.py, which owns every file in it.
- Distinctive: line 31
Leave everything outside its managed markers byte-exact.
- Very specific: line 48
If empty, abort: the plugin install is broken.
- Very specific: line 50
Check for a v0.11 footprint first: Read CLAUDE.md if it exists.
- Very specific: line 57
Run the writer: Do not hand-write the instruction block or the guide.
- Distinctive: line 89
Preserve surrounding content: Only the marker-bracketed stub and the guide file may be touched.
- Very specific: line 94
If pwd lacks all of CLAUDE.md, .git/, and a recognisable project manifest (package.json, pyproject.toml, Cargo.toml, platformio.ini, etc.), …
- Distinctive: line 104
Every lifecycle command writes a Status History entry naming who decided, and it refuses to sign on the user's behalf.
- Very specific: line 112
Read-only: it finds candidates and writes nothing.
“Common” is measured: kept by at least 6 in 10 of the 170 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
adr-kit setup
Reply in the language the user writes in; default to English. Keep command output, identifiers, paths, and ADR file content unchanged.
Setting up ADR Kit is one deterministic act (spec R19) with four modes. An
empty $ARGUMENTS runs the default register mode below. A mode name
routes to the procedure that owns it -- follow that skill file and nothing
else; each is a mode of this entry point, not a separate product:
$ARGUMENTS | Mode | Procedure |
| (empty) | register -- write the managed guidance layout | this file, below |
adopt | audit the codebase and propose ADRs, then register | skills/init/SKILL.md (/adr-kit:init) |
hooks | install or remove the pre-commit gate only | skills/install-hooks/SKILL.md (/adr-kit:install-hooks) |
upgrade | refresh copied artifacts, migrate a v0.11 footprint | skills/upgrade/SKILL.md (/adr-kit:upgrade) |
Reject any other argument instead of guessing a mode.
You are running the one-time project setup for the adr-kit plugin (register mode). Your job is to:
- Write the project's instruction layout with
scripts/setup-project.py, which owns every file in it. - Leave everything outside its managed markers byte-exact.
This is the lightweight counterpart to /adr-kit:init. Use setup when the user has an existing project, already understands their architecture, and just wants the kit registered. Use init when the user wants the kit to also audit the codebase and propose ADRs.
Backwards compatibility (v0.11 footprint)
A project that ran v0.11 /adr-kit:setup has an inline ## ADR Kit Rules section in CLAUDE.md. This skill detects that footprint and leaves it untouched — telling the user to run /adr-kit:upgrade to migrate to the v0.12 marker-bracketed stub + external guide layout. Do not silently rewrite a v0.11 footprint. The upgrade skill exists for that explicit migration.
Steps
Resolve the plugin path.
ADR_KIT="${ADR_KIT_ROOT:-${CLAUDE_PLUGIN_ROOT}}" [ -n "$ADR_KIT" ] || { echo "adr-kit: plugin root not found; set ADR_KIT_ROOT, or update or reinstall the plugin" >&2; exit 1; }If empty, abort: the plugin install is broken; tell the user to reinstall via
/plugin install adr-kit@rvdbreemen-adr-kit.- Check for a v0.11 footprint first. Read
CLAUDE.mdif it exists. If it carries an inline## ADR Kit Rulessection, stop and tell the user:Detected v0.11 ADR Kit Rules section in CLAUDE.md at line <N>. Run /adr-kit:upgrade to migrate. /adr-kit:setup is leaving the v0.11 footprint untouched.Exit without changes. A v0.11 footprint requires an explicit migration; this command never performs one silently. Run the writer. Do not hand-write the instruction block or the guide.
scripts/setup-project.pyowns the layout, and it is the only thing that knows all of it:CLAUDE.md,AGENTS.md,.github/copilot-instructions.mdand.adr-kit/ADR-guide.md. Prose in this skill describing an older layout is how the three clients drifted apart in the first place -- Codex and Copilot delegated here while this file still wrote a guide under.claude/and a stub block thatscripts/project_setup.pyclassifies as legacy.Preview first, then apply:
python3 "$ADR_KIT/scripts/setup-project.py" --client claude-code-cli --project-root . --dry-run python3 "$ADR_KIT/scripts/setup-project.py" --client claude-code-cli --project-root .The command is idempotent: re-running it on a current project changes nothing. It writes only inside its managed markers, so user content around them stays byte-exact, and it never touches
.adr-kit/ADR-guide.local.md.--clientalso acceptscodex-cliandgithub-copilot-cli, and--clientstakes a comma-separated list when a project uses more than one.- Report what it did. The command prints one line per change. Relay them, and say plainly when there was nothing to do -- a no-op is the expected outcome of a second run, not a failure.
Constraints
- Two coordinated writes. v0.12 setup writes both the stub AND the guide file. Either-or is incomplete.
- Never silently migrate v0.11. A v0.11 footprint requires explicit
/adr-kit:upgrade. Leave v0.11 alone here. - Idempotent. Re-running on a v0.12 project where everything is current is a no-op.
- Read before write. Preview with
--dry-runbefore applying; the writer reads every file it touches. - Preserve surrounding content. Only the marker-bracketed stub and the guide file may be touched. Everything else stays byte-exact.
- No em dashes in any text the skill writes (per adr-kit style).
When the user is in the wrong directory
If pwd lacks all of CLAUDE.md, .git/, and a recognisable project manifest (package.json, pyproject.toml, Cargo.toml, platformio.ini, etc.), stop and ask: I do not see a project root here (no CLAUDE.md, no .git, no manifest). Confirm you want to set up adr-kit in <pwd>? Do not silently create files in unexpected locations.
Cross-references
/adr-kit:setup adopt(alias/adr-kit:init) — full bootstrap including audit and hook installation./adr-kit:setup upgrade(alias/adr-kit:upgrade) — migrate v0.11 → v0.12 footprint without re-auditing./adr-kit:setup hooks(alias/adr-kit:install-hooks) — install the pre-commit hook independently.
Step 4c — The signer: propose, never assume
Every lifecycle command writes a Status History entry naming who decided, and it refuses to sign on the user's behalf. That refusal is right, and it should not be the user's first experience of the tool.
python3 "$ADR_KIT/bin/adr" signer --suggest --adr-dir docs/adrRead-only: it finds candidates and writes nothing. It looks at the signed-in
GitHub account (gh api user, when the CLI is available) and at
git config user.name, ranks them, and shows each with its source — a proposal
the user cannot trace is one they cannot judge, and this value lands in an
immutable history.
- Candidates found — show them and ask which to adopt, or let the user type a
different name. Then write it:
python3 "$ADR_KIT/bin/adr" signer --set "User: <chosen>". - Already configured — say so and move on. Do not overwrite it.
- Nothing found — the GitHub CLI is absent or signed out and git names nobody usable. Ask for the name outright rather than guessing.
Bot and CI identities are deliberately not offered. github-actions[bot],
runner, a bare user: those are configured values that name a machine, and
R8 asks for evidence of which human accepted a decision.
The value is machine-local by design (docs/adr/.adr-kit.local.json, gitignored)
because writing one person's name into the tracked config would sign every
teammate's acceptances. Each machine, container and CI runner needs its own.
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.

