| name | bootstrap-project |
| description | One-command new-repo setup orchestrator. Detects the stack, then runs the project-setup workflow end to end - root CLAUDE.md (/init), nested CLAUDE.md placement (/where-claude), scoped permissions (/setup-permissions), an automation proposal (propose-automation), and a couple of seed memories - pausing for approval at each step. Global and project-agnostic. Trigger when the user says "bootstrap project", "bootstrap-project", "set up this repo for Claude", "onboard this project", or "run the full project setup". |
Bootstrap a project for Claude Code (setup orchestrator)
Project-agnostic, global skill. It runs the whole new-repo setup workflow in one pass,
chaining the focused tools the user already has into a single guided sequence. It is a
thin orchestrator: it owns the order and the hand-offs, and delegates the real work
to each step's existing skill. It never duplicates their logic.
The sequence:
/init (root docs) -> /where-claude (nested CLAUDE.md placement) ->
/setup-permissions (scoped allowlist) -> propose-automation (skills/agents/hooks) ->
/setup-ci (GitHub Actions pipeline, optional) ->
/obsidian-vault (knowledge base, optional) ->
seed durable memories.
Operating principles
- Orchestrate, don't reimplement. Each step is handled by its own skill; this skill
sequences them and carries context forward. If a step's skill is missing, say so and
offer to do that step's essence inline rather than silently skipping.
- Approval gate per step. Pause after each step; show what it produced and confirm
before moving on. The user can skip any step. Never run the whole chain unattended.
- Idempotent / resumable. Detect work already done (existing root
CLAUDE.md,
existing .claude/settings*.json permissions, existing .claude/skills) and offer to
skip or update rather than redo. Safe to run on a partially-set-up repo.
- Restraint downstream. Each delegated skill already biases to restraint; do not
override that by pushing the user to accept everything.
Procedure
0. Orient (once, up front)
- Confirm the working directory is the repo root the user means (especially with
submodules/monorepos - ask which package/submodule to bootstrap if ambiguous).
- Detect prior setup: root and nested
CLAUDE.md, .claude/settings.json /
settings.local.json permissions, .claude/skills, .claude/agents. Summarize what
already exists so the run adapts instead of redoing it.
- For a large/unfamiliar repo, delegate the initial sweep to the
Explore agent.
- Show the planned sequence and let the user drop any steps before starting.
1. Root documentation -> /init
- If no root
CLAUDE.md, run /init to create one. If one exists, offer to review/update
it instead of regenerating. Pause for approval.
2. Nested CLAUDE.md placement -> /where-claude
- Invoke the
where-claude skill to get the ranked list of subdirectories worth their own
CLAUDE.md. Present it; for each one the user approves, run /init in that directory.
(where-claude reports only; the user//init create the files.) Pause for approval.
3. Scoped permissions -> /setup-permissions
- Invoke the
setup-permissions skill to scan the stack and propose narrowly-scoped
permission rules for per-rule authorization, writing approved rules to the chosen
settings file (default .claude/settings.local.json). Pause for approval.
4. Automation proposal -> propose-automation
- Invoke the
propose-automation skill to propose a short ranked plan of project skills,
agents, and hooks, and scaffold only what the user approves. Pause for approval.
5. CI pipeline -> /setup-ci (optional)
- Invoke the
setup-ci skill to scan the stack and propose a GitHub Actions CI setup
with separate jobs per concern. Present the proposed jobs; scaffold only what the user
approves.
- This step is optional: offer it with a brief rationale ("new repos benefit from CI
from day one"), but do not push if the user declines. Skip if the repo is not on
GitHub or if
gh is unavailable.
- Pause for approval.
6. Obsidian Vault -> /obsidian-vault (optional)
- Offer to create an Obsidian Vault for the repo — a structured knowledge base covering
architecture, ADRs, execution plans, and session logs. Present the vault layout before
creating anything; scaffold only after explicit approval.
- Frame it clearly as optional: "If you use Obsidian, this gives you a ready-made
knowledge base anchored to this repo." Skip without ceremony if the user declines.
- Pause for approval.
7. Seed durable memories
- Offer to write a couple of high-value project memories (type
project): the repo's
purpose/goal, key constraints, and any conventions surfaced during setup. Keep it to a
few genuinely durable facts; do not record what the code or CLAUDE.md already states.
- Update
MEMORY.md with one-line pointers, per the memory format.
8. Wrap up
- Summarize what was created/changed in each step and where.
- Remind the user that newly scaffolded skills/agents are indexed at session start, so a
restart is needed before new
/commands autocomplete.
Guardrails
- Thin orchestrator only: delegate to each step's skill; never duplicate their logic.
- Approval gate at every step; the user may skip any. Never run the chain unattended.
- Be idempotent: detect and respect existing setup; offer to update, not clobber.
- If a delegated skill is unavailable, say so explicitly rather than silently skipping.
- Respect each downstream skill's restraint and any repo integrity/firewall constraints.
- Steps 5 (setup-ci) and 6 (obsidian-vault) are explicitly optional; do not pressure
the user to accept them. A "no" is a complete and valid answer.
- Never fabricate repo facts - base every step on what you actually observed.
