Bootstrap Project

---
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
1. **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.
2. **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.
3. **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.
4. **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.