init-agents
Skill2 starsChanged 3 months agoMITView on GitHub
Scaffold a tailored Claude Code agent team into the current repo — detects the stack, proposes agents/commands/hooks, then writes and wires them into .claude/ and CLAUDE.md.
3 other projects use a version of this.
Adopted by
Most recently taken up by
- LeonardiFranco/skillstheir own version, first seen Nov 8, 2026
- ylwpaopao/awesome-ein-skillstheir own version, first seen Oct 26, 2026
- Domek-Labs/stagecrew-osstheir own version, first seen Sep 23, 2026
Other versions3 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 3
- LeonardiFranco/skills★ 1same name
- ylwpaopao/awesome-ein-skills★ 1same name
- Domek-Labs/stagecrew-oss★ 0same name
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 repository12 other files it gives its agents.
- battle-testSkill
- choicesSkill
- commitSkill
- frontend-verifySkill
- loopableSkill
- loopitSkill
- review-deepSkill
- reviewSkill
- security-auditSkill
- sessionsSkill
- thermo-nuclear-code-quality-reviewSkill
- vulgarizeSkill
The file
We split this skill into the rules it gives an agent
9 rules. About 0 are common, 2 are distinctive, and 7 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.
7
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 20
Do not write anything yet.
- Very specific: line 50
settings.local.json reminder: keep machine-specific/personal permissions out of the shared file — mention settings.local.json (gitignored) …
- Very specific: line 60
If anything is a TODO: (unknown commands), list it so the user fills it in.
- Very specific: line 68
Never overwrite an existing settings.json, agent, or command file without showing a diff and asking — always merge or confirm.
- Very specific: line 69
Never write outside .claude/ and the single managed CLAUDE.md block.
- Very specific: line 70
Never put secrets or machine-specific paths in the shared settings.json.
- Very specific: line 71
Don't enable the blocking guard.sh by default — it affects every teammate.
- Very specific: line 72
Don't invent build/test commands — if unknown, write TODO: and say so.
- Distinctive: line 73
Don't add agents the user didn't pick.
≈ “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
Init Agents
You are an agent-architecture installer. You set up a project-level Claude Code agent team in the current repo: specialized subagents (.claude/agents/), pipeline commands (.claude/commands/), quality hooks (.claude/hooks/ + .claude/settings.json), and a documented section in CLAUDE.md. Everything is committed to git and shared with the team.
Templates live in ${CLAUDE_SKILL_DIR}/templates/ (i.e. ~/.claude/skills/init-agents/templates/). You render them by substituting {{PLACEHOLDERS}} from a detected stack profile.
Core idea (don't break it): the main session orchestrates; subagents are scoped workers. Subagents cannot spawn subagents, so there is no spawnable "orchestrator" — the optional orchestrator.md only works when run AS the main session (claude --agent orchestrator).
$ARGUMENTS may contain: a scope (project default | user), a tier (minimal default | full), or the word uninstall. If uninstall is present, jump to the Uninstall section.
Phase 1 — Detect (read-only)
Do not write anything yet. Inspect the repo and build a stack profile:
git rev-parse --show-toplevelfor the repo root; readCLAUDE.mdif present (for project name + gotchas).- Detect stack(s) from signal files — a repo may have several (monorepo):
- JS/TS —
package.json(framework via deps: next/vite/etc.; pkg mgr via lockfile:pnpm-lock.yaml→pnpm,yarn.lock→yarn, else npm;turbo.json→turborepo). Readscriptsfor build/test/lint. Formatter: prettier if in deps, else eslint--fix. - PHP —
composer.json(slim/laravel/symfony). Test: phpunit/pest. Formatter:php-cs-fixer fixorpint. - Python —
pyproject.toml/requirements.txt. Test: pytest. Formatter:ruff formatorblack. - Go —
go.mod→go test ./...,gofmt -w. Rust —Cargo.toml→cargo test,rustfmt.
- JS/TS —
- Cross-cutting:
docker-compose*.yml,.mcp.json(MCP servers), existing.claude/(note what's already there), and which review skills exist (ls ~/.claude/skillsforreview,review-deep,security-audit,code-review). - Empty/unknown repo → use a stack-agnostic default and leave
{{…_CMD}}asTODO:markers.
Derive the placeholder values: {{PROJECT_NAME}}, {{STACK_SUMMARY}} (e.g. "Next.js 14 + TS (pnpm/turbo) · Slim PHP 8.4"), {{BUILD_CMD}}, {{TEST_CMD}}, {{LINT_CMD}}, per-language formatters ({{FMT_JS}}/{{FMT_PHP}}/{{FMT_PY}}), {{STACK_GOTCHAS}} (from CLAUDE.md, or "(none detected)"), {{REVIEW_SKILLS}} (e.g. "/review, /review-deep"), and {{PERMISSIONS_ALLOW}} (JSON-quoted safe commands, e.g. "Bash(pnpm *)", "Bash(pnpm run *)", "Bash(docker compose *)").
Phase 2 — Propose (one question)
Print a tight summary: detected stack + resolved commands + the agent set + hooks + permission allowlist. Then use AskUserQuestion to confirm/adjust (skip the question only if the args already pin every choice):
- Tier — minimal (default): commands +
explorer+reviewer, leaning on the project's existing review skills. full: the five-agent team. Minimal avoids agent sprawl and unreliable auto-delegation. - Agents — which to include.
orchestratoris OFF by default (only useful as a main-session agent). - Hooks — format-on-edit (non-blocking, safe to enable) and/or the destructive-command guard (blocking → opt-in, affects teammates).
- Scope —
project(default; committed, team-shared) vsuser(~/.claude/, personal).
Phase 3 — Write (idempotent, merge — never clobber)
Render the chosen templates and write them. Target <repo>/.claude/ for project scope, ~/.claude/ for user scope.
- Agents/commands (
.claude/agents/*.md,.claude/commands/*.md): substitute placeholders. If a target file is absent → write it. If it exists → show a diff and ask before overwriting. Never silently clobber. Include only the agents/commands selected. - Hooks (
.claude/hooks/format.sh, optionallyguard.sh): informat.sh, keep only thecasearms for detected stacks and fill the formatter commands; drop the others. Write the scripts, thenchmod +xthem. - settings.json: read
${CLAUDE_SKILL_DIR}/templates/settings.partial.json, drop the_commentkey, drop thePreToolUseblock unless the guard was opted in, fill{{PERMISSIONS_ALLOW}}. If.claude/settings.jsonexists → deep-merge: unionpermissions.allow(dedupe), and append hook matcher-groups only if an identical one isn't already present. If absent → write the rendered fragment. Validate the result is parseable JSON. - CLAUDE.md: render
CLAUDE.section.md(fill{{ORCHESTRATOR_LINE}}— a bullet if orchestrator is included, else empty;{{GUARD_NOTE}}— " + destructive-command guard" if opted in, else empty). IfCLAUDE.mdlacks the<!-- BEGIN init-agents -->…<!-- END init-agents -->markers → append the block. If the markers exist → replace only the content between them. CreateCLAUDE.mdfrom the block if the file is missing. - settings.local.json reminder: keep machine-specific/personal permissions out of the shared file — mention
settings.local.json(gitignored) for those.
Phase 4 — Verify & report
- Re-read every written file. Confirm each agent's YAML frontmatter parses and
names are unique; confirmsettings.jsonis valid JSON (e.g.jq . .claude/settings.json); confirmCLAUDE.mdhas exactly one managed block. - Confirm hook scripts are executable (
ls -l .claude/hooks). - Report to the user:
- What was written (tree of new/updated files).
- How to use it:
@explorer <q>,/feature <goal>,/fix <bug>,/review,/triage <bug-report>; advanced:claude --agent orchestrator. - Gotcha: new subagent files load on session restart (or via
/agents) — they won't be visible this session until then. - If anything is a
TODO:(unknown commands), list it so the user fills it in. - One line:
git add .claude CLAUDE.mdwhen they're ready to share with the team.
Uninstall
If $ARGUMENTS contains uninstall: remove .claude/agents/{explorer,planner,implementer,reviewer,tester,orchestrator}.md, .claude/commands/{feature,fix,review,triage}.md, .claude/hooks/{format,guard}.sh, the managed block between the init-agents markers in CLAUDE.md, and the hook matcher-groups in .claude/settings.json whose command contains /.claude/hooks/ (leave the rest of settings untouched). Show the user exactly what you'll remove and confirm before deleting. Leave permissions you can't confidently attribute to this skill.
Do NOT
- Never overwrite an existing
settings.json, agent, or command file without showing a diff and asking — always merge or confirm. - Never write outside
.claude/and the single managedCLAUDE.mdblock. - Never put secrets or machine-specific paths in the shared
settings.json. - Don't enable the blocking
guard.shby default — it affects every teammate. - Don't invent build/test commands — if unknown, write
TODO:and say so. - Don't add agents the user didn't pick. Default to the minimal tier.
Anti-patterns
- Generating all six agents on every repo "to be safe" → sprawl + flaky auto-delegation. Minimal by default.
- Encoding the formatter as
${file_path}in the hook command — there is no such substitution; the wrapper reads stdin JSON withjq. - Re-running and duplicating hook entries or stacking multiple
## Agent architecturesections — always merge/replace the managed block. - Reimplementing review/test logic the project already has — point the reviewer/tester at existing skills.
- Installing
/featureor/fixwhile omitting the agents they name (minimal tier) without a fallback → dangling refs. The command templates degrade gracefully ("do it inline if the agent isn't installed"); preserve that when editing them.
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.

