capabilities-manager
Manage capa CLI configuration — `capabilities.yaml` / `capabilities.json`, skills, MCP servers, tools, hooks, sub-agents, rules, plugins, AGENTS.md / CLAUDE.md, security options, tool exposure modes, `capa wrap` shadow workspaces, `--passthrough` native writes, registries (including Claude marketplaces), activity traces, and the local Web UI. Use whenever the user edits the capabilities file, runs any `capa` command (init, install, add, wrap, clean, sh, start/stop/restart/status, auth, upgrade, cache, registry), wires up an MCP server, adds a skill from GitHub / GitLab / a registry / a remote
npx skills add infragate/capa --skill capabilities-manager --agent claude-code
Same command for any agent — swap --agent for codex, cursor, copilot.
Weekly change comes from our own snapshots, not the repository page — it measures attention, not adoption.
# Capabilities Manager The capa CLI keeps a single source-of-truth file — `capabilities.yaml` (or `.json`) — that describes everything an agent can do in this project: skills, MCP servers, tools, hooks, sub-agents, rules, plugins, and per-provider files (`AGENTS.md`, `CLAUDE.md`). Editing that file and running the right `capa` command is the whole loop. This skill is the routing layer for that loop. The actual command reference, schema, full YAML examples, and troubleshooting tables live in `references/`. Load the one you need rather than re-deriving its contents — they are kept up to date and are the authoritative source. ## How capa works (one screen) 1. **The file is the source of truth.** `capabilities.yaml` declares what gets installed. Capa never auto-discovers anything from `.claude/`, `.cursor/`, etc. — if it's not in the file, capa won't manage it. (Onboarding an already-configured project is the `bootstrap` skill's job.) 2. **`capa install` writes everything.** Skill directories under each provider, MCP client config (`.mcp.json`, `.cursor/mcp.json`, etc.), `AGENTS.md` / `CLAUDE.md` blocks, hook entries, rules — all rewritten from the file. Anything labeled `name: capa:<i
- How capa works (one screen)
- Routing — load the reference that matches the task
- Pitfalls worth heading off
- @ vs :: in def.repo
- ${VarName} is a capa placeholder, not a shell variable
- Tool naming: @server.tool vs plain id
- Tool exposure mode shapes everything downstream
- Activity traces are on by default
- Conventions that prevent surprises
- After making changes
- References
What does the capabilities-manager skill do?
Manage capa CLI configuration — `capabilities.yaml` / `capabilities.json`, skills, MCP servers, tools, hooks, sub-agents, rules, plugins, AGENTS.md / CLAUDE.md, security options, tool exposure modes, `capa wrap` shadow workspaces, `--passthrough` native writes, registries (including Claude marketplaces), activity traces, and the local Web UI. Use whenever the user edits the capabilities file, runs any `capa` command (init, install, add, wrap, clean, sh, start/stop/restart/status, auth, upgrade, cache, registry), wires up an MCP server, adds a skill from GitHub / GitLab / a registry / a remote
How do I install it?
Run `npx skills add infragate/capa --skill capabilities-manager --agent claude-code` — it drops the skill into your project so the agent can pick it up. Swap the --agent value for codex, cursor or copilot if you use one of those.
Where does this skill come from?
From infragate/capa, a repository with 680 stars. We read it straight from the repository tree rather than a submitted listing, so what you see here is what is actually published.
Is a popular skill a good skill?
Not necessarily. Stars measure attention, not adoption — a repository can trend for a week and be abandoned. That is why we show the weekly change from our own snapshots next to the total, instead of a single flattering number.