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/<id>/ 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/<id>/ into the project's .claude/skills/<id>/. Copy semantics (never destructive):

• If the destination file does not exist → copy.
• If it exists → write the new version alongside as <file>.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:

<!-- BEGIN INSTALLED-ASSETS -->
| If request touches… | Load |
|---|---|
| <trigger phrase, drawn from the skill's own description> | `<asset-id>` skill |
<!-- END INSTALLED-ASSETS -->

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

- <asset-id> (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.