Capability Discovery

The pipeline should never invent tools. Before drafting a kit that references GitHub Actions, Supabase, Codex, or any other external dependency, check what actually exists.

What we detect

• CLI tools on $PATH: gh, git, node, go, rustc, cargo, python3, pip, docker, vercel, supabase, firebase, wrangler, ffmpeg, playwright, codex, graphify.
• MCP servers: parsed from .mcp.json in the project root and ~/.claude.json (user level).
• Claude Code plugins: parsed from ~/.claude/plugins/installed_plugins.json.
• Codex: presence of the codex CLI (enables peer-review commands).
• Knowledge graph: presence of graphify-out/graph.json (enables the graphify-integration skill).

Running discovery

node "${CLAUDE_PLUGIN_ROOT}/scripts/cavekit-tools.cjs" discover

Writes .cavekit/capabilities.json:

{
  "discovered_at": "2026-04-17T14:22Z",
  "cli_tools": {
    "gh": true, "git": true, "node": true, "codex": false
  },
  "mcp_servers": ["codex-reviewer", "graphify"],
  "plugins": [],
  "codex": { "available": false }
}

How other commands use it

• /ck:sketch — reads capabilities before proposing integrations. If a kit would need a missing tool, it either adds a "Setup" task to the build site or asks the user whether to proceed without it.
• /ck:map — flags tasks that depend on missing capabilities as blocked: setup-required.
• /ck:make — refuses to dispatch subagents that require a missing MCP server.
• /ck:check — includes a "Capability Coverage" section in the inspect report.

When to re-run

• After installing a new CLI tool.
• After adding or removing an MCP server.
• At the start of every new project (via /ck:init).
• Whenever a task fails with "command not found".

The file is cheap to regenerate — always discover, never guess.

What we deliberately do not detect

• Network-accessible APIs behind credentials. Availability is not reachability; kits should record credentials as a separate concern (never committed).
• IDE extensions. They are not scriptable from the loop and would create false assurances.
• Language versions. Version-pinning is the project's responsibility (package.json / go.mod / pyproject.toml); discovery only confirms executables exist.