# Project Bootstrap > Guided install of reusable Claude tooling from the clybor-claude-tooling catalog into a new project. Reads catalog.json, asks up to 4 project-profile questions, proposes a matching install set with rationales, copies assets into .claude/, adds a router row in CLAUDE.md for each one so it is actually reachable, fills the catalog-declared adaptation tokens in one batch-confirm round, and writes a TOOLING.md manifest recording what was installed. Use when the user says "bootstrap this project", "set up claude tooling for this project", "install tooling from the catalog", "what tooling from my catalog fits this project", or "init this repo from clybor-claude-tooling". Works for both Claude Code and Cowork projects. - Skill: `shawnclybor/project-bootstrap` (Agent Skill) - Install (CLI): `npx skillmds@latest add shawnclybor/project-bootstrap` - Raw SKILL.md: https://api.skillmd.com/api/skills/shawnclybor/project-bootstrap/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: shawnclybor (https://skillmd.com/u/shawnclybor) - Updated: 2026-09-21 - Page: https://skillmd.com/skills/shawnclybor/project-bootstrap --- # Project Bootstrap Sets up a new project with tooling from the catalog. Seven steps, one at a time. The catalog lives at the clybor-claude-tooling repo root: `catalog.json` indexes every asset under `assets/skills//` with its domains, requirements, and adaptation tokens. This skill is the consumer side: filter, propose, install, personalize, record. ## Step 1 — Read the catalog, profile the project Locate the catalog repo (default `~/gits/clybor-claude-tooling/`; ask if not found). Read `catalog.json`. Then ask the user AT MOST 4 questions, in one round: 1. **Project type** — consulting engagement / coding project / research / mixed? 2. **Client surface** — Claude Code, Cowork, or both? (filters on each asset's `targets`) 3. **Domains in play** — pick from the domain values present in the catalog (show them). 4. **Seed values** — the project/client name and any obvious adaptation values (e.g., where notes and tasks should live, if known). If the user's request already answers a question, don't re-ask it. Fewer than 4 is better than 4. ## Step 2 — Propose the install set Filter the catalog on `targets` + `domains`. Present the proposed set as a short list, one line per asset: name, one-line rationale drawn from its `summary`, and its adaptation tokens. Mark anything borderline as optional. Wait for approval or edits. ## Step 3 — Copy assets in For each approved asset, copy `assets/skills//` into the project's `.claude/skills//`. Copy semantics (never destructive): - If the destination file does not exist → copy. - If it exists → write the new version alongside as `.new` and tell the user to diff before merging. Never overwrite. ## Step 4 — Route every installed asset in CLAUDE.md **An installed skill the router never mentions is unreachable.** A cold session follows CLAUDE.md's routing table and nothing else — it will not discover a skill by listing `.claude/skills/`. Installing without routing ships a capability that cannot fire. For each asset installed in Step 3, append one row inside the sentinel block in the project's CLAUDE.md: ``` | If request touches… | Load | |---|---| | | `` skill | ``` Rules: - Write the rows **between the sentinels**, replacing the `(none yet …)` placeholder comment. Never rewrite the table above the sentinels. - The trigger column comes from the asset's `description` frontmatter, not its `summary` — the description is what the trigger conditions actually are. One line, concrete. - If CLAUDE.md has no sentinel block (a repo predating this template), insert the whole block immediately after the main routing table and say so in the Step 7 report. - Re-installs: update the existing row for that asset-id, don't add a second. ## Step 5 — Fill adaptation tokens (one batch-confirm round) Collect every token declared in the installed assets' `adaptation_points`. Propose a value for each in ONE message, using Step 1's seed answers — assumptions in [brackets] so the user can verify or swap. Example: `{{...RECORD_SYSTEM}}` → "[Notion Note DB]". After the user confirms or corrects, apply all fills with Edit. Do not ask token-by-token questions; one confirmation round total. Template-type assets (e.g. `governance-skill-template`) fill like everything else: seed them with the project's FIRST concrete domain (its primary external system). The unfilled master stays in the catalog — for additional domains, re-copy from the catalog rather than un-filling the installed seed. ## Step 6 — Write TOOLING.md At the project root, write a manifest. One line per installed asset, exactly: ``` # TOOLING.md — installed from clybor-claude-tooling - (catalog_version: X.Y.Z, source: clybor-claude-tooling) ``` Use the `catalog_version` from the catalog.json you read in Step 1. This manifest is what a later sync pass diffs against the catalog. ## Step 7 — Verify and report - `grep -r "{{" .claude/skills/` in the project must return nothing (all tokens filled; unfilled tokens mean Step 5 missed one — fix before reporting). - **`bash scripts/check-knowledge.sh` must pass.** Its skill-router gate fails when an installed skill has no router row — that is Step 4 catching itself. If the project has no `scripts/check-knowledge.sh`, check by hand: every directory under `.claude/skills/` is named somewhere in CLAUDE.md. - `chmod +x` any installed hook files (no-op when the install set contains no hooks — v1 catalog ships skills only; keep the step for future hook assets). - Report: assets installed, router rows added, tokens filled, manifest path. Two or three sentences. ## Ground rules - One step at a time. Don't run Steps 1-7 in a single message wall. - Skips are mostly fine. If the user passes on a step (or wants no token fills), move on. **Step 4 is the exception** — it is not optional and not deferrable. An unrouted skill is an install that did nothing. Copy without route = do not report the asset as installed. - Keep each message short — a few sentences plus the proposal or question, not a wall. - A mid-flow skill invocation is expected. If the user triggers another skill while bootstrapping, help with it briefly, then return to where you left off — don't let the skill invocation end the setup. ## Edge cases - **No catalog found** — ask for the repo path; offer to clone if the user gives a URL. - **Asset already installed** (TOOLING.md exists listing it) — propose only the delta; re-installs follow the `.new` rule from Step 3. - **An asset's `requires.mcp` names a server the project lacks** — flag it in Step 2's proposal ("needs X connected") rather than silently installing.