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.