bootstrap

What it does

Turns an existing project that has MCP servers, skills, rules, hooks, and sub-agents across several provider-specific directories into a clean, reproducible capabilities.yaml managed by capa. It performs discovery, migration, and synthesis to produce a single capabilities.yaml at the repo root.

How it works

• Preflight checks include ensuring capa is installed, Git state sanity, and branch handling by creating a capa/bootstrap branch when on a main-like branch.
• Discover: scans the repo for agent configurations across providers, resolving symlinks and submodules, excluding common build dirs. Builds an inventory snapshot with sections like mcp_servers, skills, rules, hooks, subagents, symlinks, submodules, and ignored_dirs_present.
• Plan: presents the inventory and explains why moves are necessary. Decides which provider-specific items move to shared dirs, how to reference them (e.g., .claude/skills/foo/ → skills/foo/ with type: local and def.path), and which providers to declare. Discusses .gitignore changes and potential conflicts.
• Migrate: executes moves with git mv per category and shows a rename list for verification.
• Synthesize: writes capabilities.yaml with a skeleton structure including providers, options, and empty or populated sections for skills, servers, tools, rules, hooks, subagents, plugins. Always includes capabilities-manager and sorts by id. Documents how to choose MCP server configs and how to reference tools.
• Verify: runs capa install and surfaces installed items, blockers, and remaining credential prompts.
• Inspect tools: populates the tools: section by querying MCP servers for available tools and suggesting appropriate ids, ensuring id naming excludes server prefixes and matches the described conventions.

When to use it

Use when the user has a repo that already works with at least one AI coding agent but has never run capa init. Trigger words include: "bootstrap capa", "capify", "set capa up on this repo", "convert my .claude/.cursor config to capa", or asks how to turn ad-hoc provider configurations into a capabilities file. If a capabilities.yaml already exists, this tool defers to capabilities-manager instead.

What it can touch

• provider config dirs (e.g., .claude, .cursor, .codex, etc.) to migrate into shared top-level dirs (skills/, rules/, hooks/).
• The project root for the synthesized capabilities.yaml.
• .gitignore entries as planned in Phase 3.

Caveats

• Do not move files without user sign-off during Phase 3. Phase transitions require user confirmation before Phase 4 migration.
• If Phase 6 yields empty tools for a server, the agent will prompt the user to complete authentication per the guidance in Phase 6.
• The tool relies on capabilities-manager for schema details; it defers exact field shapes to that skill when composing entries.