CAPA
Declare skills, tools, rules, sub-agents, and MCP servers once in capabilities.yaml — CAPA syncs them to 35+ AI coding agents and runs a local MCP gateway, ending scattered agent config.
Evidence shows least-privilege design (per-sub-agent filtered MCP endpoints, marker-block surgical writes, shadow workspace), user confirmation of the executable surface before install (interactive default, --yes for CI), secret redaction in the activity tracer, and checksum verification on upgrade. Deducted: dependencies declared with wide ^ ranges with no lockfile/audit evidence; registry adapters are executable TypeScript with only a prompt for users to self-review; rollback limited to capa clean/--prune with no versioned restore of provider files; no maintainer attribution or governance info for infragate.
CLI semantics are consistent between README and cheat sheet; provider support and limits (Copilot not wrappable, Windows ARM fallback) are internally consistent. Deducted: mostly floating ^ dependency ranges, Bun pinned only in the release workflow; failure handling described only as error rows in the activity UI, with no documented error messages or exit-code conventions.
Audience is team-level AI coding agent users; scenarios span multi-provider, CI, interactive mode, three platforms, and Windows Developer Mode limits, all documented. Deducted: boundaries rely on NOTE/TIP callouts; the 19–40% token saving claim lacks stated conditions; trigger precision (lazy-load and per-sub-agent filtering rules) is summarized without rule documentation.
Clear information architecture (Why→Features→Install→Quick start→architecture diagram→cheat sheet→docs/); install notes cover all three platforms with checksums and build-provenance attestation; known limitations (Copilot wrap, Windows ARM/x86) are explicit. Deducted: a MIT badge is referenced but the LICENSE file body is not among the provided sources (metadata says unknown), so license scores 1; no CHANGELOG (release notes generated); maintenance responsibility limited to SECURITY.md response SLAs with no maintainer/roadmap commitments.
Good output usability: capa sh tool layer, Web UI, dry-run, and passthrough provide multiple inspectable outputs. Marginal value is real (unified config for 35+ agents plus a local MCP gateway with sub-agent isolation is a rare combination). Deducted: the 19–40% token saving rests on a single '150 trials' sentence with no methodology to verify, and the cost of running a local server/Web UI (port 5912, resources) is not quantified.
claim_traceability: the token-saving and '35+ agents' claims cannot be traced to method or a list within the provided files; cross_source_corroboration: a test badge and test.yml are referenced but test code is not in the provided files, so no cross-checking is possible; fact_inference_separation: the README distinguishes facts from hints via NOTE/TIP/IMPORTANT, which is good practice, but claims generally lack separated evidence, limiting the static review to 1.
- The installer uses a curl | sh pattern, and third-party registry adapters are executable TypeScript — review their source and origin before enabling.
- The first-install executable-surface confirmation is the primary authorization gate; --yes in CI skips it, so ensure capabilities.yaml is reviewed in CI environments.
- The 19–40% token saving is a self-reported '150 trials' figure, independently unverified — do not use it as a procurement basis.
- Dependencies use floating ^ ranges; assess supply-chain risk yourself and consider pinning and auditing.
- A MIT badge is referenced but the LICENSE file body is absent from the provided sources — verify the license before use.
What does this agent do, and when should you use it?
CAPA (GitHub: infragate/capa) is a package manager and MCP gateway for AI coding agents. You declare skills, tools, rules, sub-agents, hooks, and plugins in a single capabilities.yaml; running capa install writes them into Cursor, Claude Code, Codex, Windsurf, GitHub Copilot, and 35+ other agents in their native formats. SHA pins land in capabilities.lock, and marker blocks ensure surgical writes that leave hand-edited content alone. At runtime it is a local MCP gateway: every agent connects to one local endpoint (default http://localhost:5912) through which CAPA proxies upstream stdio/HTTP/SSE servers, lazy-loads tools on demand, and scopes what each sub-agent can call. An embedded React Web UI provides a capabilities editor, registry browsing, OAuth setup, and live activity traces. It runs on macOS, Linux, and Windows.
The flow starts with capa init, which creates capabilities.yaml and registers the project with the local CAPA server (default port 5912). You add capabilities with capa add — e.g., a skill (capa add vercel-labs/agent-skills@web-researcher), an MCP server (capa add --server --id brave --cmd npx --arg @brave/brave-search-mcp), or via registry search (capa registry search skills-sh "research"). capa install resolves SHAs, fills the cache, writes per-provider files (.cursor/rules/, .claude/agents/, AGENTS.md, etc.), and records pins in capabilities.lock. At runtime the capa gateway proxies all MCP calls: tools load on demand (setup_tools/call_tool), each sub-agent gets a filtered endpoint, and ToolCallTracer records activity with secrets redacted. capa sh turns every configured tool into a terminal command. capa wrap launches agents (Cursor, Claude, Codex, Gemini CLI, etc.) inside a shadow workspace under ~/.capa/workspaces/ so provider directories never touch the real repo. Plugins are installed by cloning the repo, reading Claude (.claude-plugin/) or Cursor (.cursor-plugin/) manifests, and merging their skills, MCP servers, rules, sub-agents, and hooks into the same install pipeline. The Web UI, served by the local server, syncs edits back to capabilities.yaml via a file watcher.
- Team leads who want clones to carry an identical agent setup — SHA pins in capabilities.lock mean 'the teammate who clones tomorrow gets the exact setup you have today.'
- Developers using several AI coding agents (Cursor, Claude Code, Codex, etc.) who want one declarative file instead of config scattered across CLAUDE.md, .cursor/rules/, AGENTS.md, and MCP JSON.
- Cost-conscious teams: on-demand tool loading instead of front-loading the whole catalog reportedly cuts 19–40% tokens across 150 trials on claude-opus-4-8.
- Users worried about over-privileged agents: sub-agent isolation filters the MCP endpoint so research agents never inherit tools like git push.
- Developers trialing new agents without polluting their repo: capa wrap runs Cursor, Claude, Codex, Gemini CLI and more from a shadow workspace.
- Engineers who need to audit agent behavior: the Activity page shows a live feed and timelines of MCP calls, shell tools, and agent spans.
What are this agent's strengths and limitations?
- One capabilities.yaml fans out to 35+ agents' native layouts with marker-block surgical writes that preserve hand edits
- capabilities.lock provides SHA pins for reproducible agent environments
- Local MCP gateway lazy-loads tools on demand — README reports 19–40% token savings across 150 trials on claude-opus-4-8
- Per-sub-agent tool filtering enforces permission isolation; research agents can't reach git push
- capa wrap shadow workspaces let you trial agents without touching your real repo
- Embedded Web UI covers live editing, registry browsing, OAuth setup, and secret-redacted activity traces
- GitHub Copilot cannot be wrapped yet — it owns shared .github/ and .vscode/ trees that need subpath exclusions
- On Windows, shadow-workspace symlinks require Developer Mode or an elevated shell
- Most registry adapters are executable TypeScript fetched into ~/.capa/registries-managed/ — source must be reviewed before enabling third-party registries
- First capa install prompts to confirm the executable surface (MCP stdio servers, hooks, etc.); CI must pass --yes
- Passthrough mode skips the lockfile and managed-file tracking; tool aliases, defaults, and formatters require managed mode
- The GitHub metadata shows License: unknown — verify licensing terms before adoption
How do you install or deploy this agent?
macOS/Linux: curl -LsSf https://capa.sh/install.sh | sh. Windows: powershell -ExecutionPolicy ByPass -c "irm https://capa.sh/install.ps1 | iex". Then cd into your project and run capa init to create capabilities.yaml and register with the local server (default http://localhost:5912).
How do you use this agent?
1) Run capa init. 2) Add capabilities: capa add vercel-labs/agent-skills@web-researcher, capa add --server --id brave --cmd npx --arg @brave/brave-search-mcp. 3) Run capa install (use --yes in CI, --dry-run to preview). 4) Run tools from the terminal: capa sh brave search --query "…". 5) Run capa status to get the Web UI URL, then edit skills/tools/rules/hooks/plugins/agents in the browser with live YAML sync. 6) Optionally capa wrap cursor/claude/codex to run agents in a shadow workspace; capa stop halts the server and wrap sessions.
How does this agent compare with similar options?
The README positions CAPA as 'the package manager and MCP gateway for AI coding agents' against the status quo of config scattered across CLAUDE.md, .cursor/rules/, AGENTS.md, MCP JSON, hooks, and skill folders with no pins and no sync. The repository itself names no other specific competitor.