Capability Discovery
Scan the real environment for CLIs, MCP servers, and Claude plugins before Cavekit kits assume tools that are not installed.
Overview
Capability Discovery is an agent skill most often used in Validate (also Build agent-tooling) that detects MCP servers, plugins, and CLI tools and writes .cavekit/capabilities.json.
Install
npx skills add https://github.com/juliusbrussee/cavekit --skill capability-discoveryWhat is this skill?
- Detects CLI tools on PATH including gh, git, docker, vercel, supabase, codex, playwright, and more listed in the skill
- Parses MCP servers from project .mcp.json and user ~/.claude.json
- Reads Claude Code installed plugins from ~/.claude/plugins/installed_plugins.json
- Writes .cavekit/capabilities.json via cavekit-tools.cjs discover or /ck:init --tools-only
- Flags optional graphify-out/graph.json for knowledge-graph integration
Adoption & trust: 4 installs on skills.sh; 1k GitHub stars; 2/3 security scanners passed (skills.sh audits).
What problem does it solve?
Your agent or kit template assumes gh, Supabase, or MCP servers that are not actually configured in this environment.
Who is it for?
Indie developers starting or refreshing a Cavekit project who need an honest toolchain inventory before generating kits.
Skip if: Replacing package managers or silently installing missing CLIs—discovery reports truth; it does not provision cloud accounts.
When should I use this skill?
Phrases like “what do we have available”, “what’s installed”, “detect tools”, “can we use X”, or Cavekit /ck:init --tools-only before kits imagine dependencies.
What do I get? / Deliverables
Cavekit and your agent read a fresh capabilities.json so plans only reference tools and integrations that discovery proved present.
- .cavekit/capabilities.json with cli_tools, MCP, plugins, and discovery timestamp
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
First appears in Validate when you scope what dependencies exist before committing to a kit or build plan—prevents imaginary GitHub Actions or Supabase bindings. Scope fits because output is an inventory decision: what is actually on PATH and in MCP config, not implementation code yet.
Where it fits
Before approving a kit that deploys via Vercel and Supabase, run discover so the plan only enables steps when those CLIs return true.
When generating agent workflows that call gh or Codex, bind commands to capabilities.json so missing codex:false skips peer-review paths.
After a teammate adds a new MCP server to .mcp.json, re-run discover so iteration scripts stop referencing stale server lists.
How it compares
Environment inventory checker for Cavekit—not a generic npx skills.sh installer or cloud IAM auditor.
Common Questions / FAQ
Who is capability-discovery for?
Solo builders using Cavekit in Claude Code who want kits and agents to reference only real MCP servers, plugins, and PATH binaries.
When should I use capability-discovery?
At Validate when scoping a project (“what’s installed”, “can we use X”), at Build before agent-tooling kits ship, and after you add MCP or plugins to refresh capabilities.json.
Is capability-discovery safe to install?
It reads local config paths (.mcp.json, ~/.claude.json, plugin manifests); review the Security Audits panel on this page before running in sensitive environments.
SKILL.md
READMESKILL.md - Capability Discovery
# 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 ```bash node "${CLAUDE_PLUGIN_ROOT}/scripts/cavekit-tools.cjs" discover ``` Writes `.cavekit/capabilities.json`: ```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.