by infragate
One capabilities.yaml wires skills, tools, rules, sub-agents, MCP servers, and plugins into Cursor, Claude Code, Codex, Windsurf, GitHub Copilot, and 30+ other AI coding agents
# Add to your Claude Code skills
git clone https://github.com/infragate/capaLast scanned: 6/11/2026
{
"issues": [
{
"file": "README.md",
"line": 84,
"type": "dangerous-command",
"message": "Dangerous command (pipe remote script to shell): \"curl -LsSf https://capa.infragate.ai/install.sh | sh\"",
"severity": "low"
}
],
"status": "PASSED",
"scannedAt": "2026-06-11T08:47:49.001Z",
"npmAuditRan": true,
"pipAuditRan": true,
"promptInjectionRan": true
}No comments yet. Be the first to share your thoughts!
30 days in the Featured rail · terms & refunds
CAPA is the package manager for AI coding agents. Declare your skills, tools, rules, sub-agents, MCP servers, and plugins once in capabilities.yaml, run capa install, and CAPA writes them into Cursor, Claude Code, Codex, Windsurf, GitHub Copilot, and 35+ other agents.
An AI coding agent needs to know when to act and to have the tools to act with. Wiring that up usually means scattering config across half a dozen files: MCP servers in one place, skill markdown in another, team conventions in CLAUDE.md, Cursor rules in .cursor/rules/, a half-finished onboarding doc somewhere in Notion. Nobody's setup matches anyone else's.
CAPA collapses that into one capabilities.yaml next to your code. You list your skills (markdown that tells the agent how to do something), the tools each skill needs (MCP calls and shell commands), your rules, your sub-agents, and any plugins you want pulled in. capa install does the rest. Cursor gets .cursor/rules/. Claude Code gets .claude/agents/ and CLAUDE.md. Codex gets AGENTS.md. Each provider on your list gets the files it expects, with capa-managed marker blocks for the parts it owns.
One file, version controlled, pinned by capabilities.lock, cached by SHA. The teammate who clones tomorrow gets the same bytes you got today.
CAPA is equipped with local web UI. You can visualize your capabilities.yaml, browse registries, manage credentials, and see exactly what each agent will receive.
The project view shows installed plugins, configured providers, and your full capability inventory. The bar across the top tracks token savings from on-demand tool exposure: the agent sees only the tools it's actively using, and pulls any of the rest in by name when it needs them.
Scrolling down the same page brings up sub-agents, rules, project options, and credentials. Every entry carries an INLINE / GITHUB / REMOTE badge so you can see at a glance where each one came from.
The Registries tab pulls skills and plugins from external catalogs. Need a private one? Run capa registry add owner/repo@my-adapter (or use the Manage registries page). capa fetches the adapter from GitHub, GitLab, or an HTTPS URL, validates it, and it shows up here too.
capa sh) can call..cursor/rules/, Windsurf .windsurf/rules/, Copilot's instructions file, or a managed marker block in AGENTS.md / CLAUDE.md for providers without a rules directory. Glob scoping works.beforeShell or afterFileEdit once and capa translates them into each provider's hook config (.claude/settings.json, .cursor/hooks.json, .codex/config.toml, .gemini/settings.json), tagging each one with capa:<id> so user-authored entries are never touched. Providers without hook support emit a warning and skip.capa add and the web UI. Add a registry with capa registry add owner/repo@my-adapter (GitHub/GitLab/HTTPS sources, slug auto-derived, adapter validated before install) and it shows up too.capabilities.lock records resolved commit SHAs. A SHA-keyed content cache makes repeat installs near instant..env.capabilities-manager skill teaches the agent how to read and edit its own capabilities.yaml.macOS and Linux:
curl -LsSf https://capa.infragate.ai/install.sh | sh
Windows:
powershell -ExecutionPolicy ByPass -c "irm https://capa.infragate.ai/install.ps1 | iex"
cd your-project
capa init
This drops a capabilities.yaml next to your code.
Pull a skill from any public GitHub repo:
capa add anthropics/skills@frontend-design
capabilities.yamlproviders:
- cursor
- claude-code
skills:
- id: frontend-design
type: github
def:
repo: anthropics/skills@frontend-design
- id: web-researcher
type: inline
def:
description: Search the web for fresh information
requires:
- "@brave.search"
content: |
---
name: web-researcher
description: Use when you need current information from the web.
---
Use `brave.search` and always cite a link.
rules:
- id: commit-style
type: inline
description: Conventional Commits
alwaysApply: true
content: |
Always use Conventional Commits (feat/fix/chore/docs/refactor).
Subject ≤ 72 chars, imperative mood, no trailing period.
- id: typescript-conventions
type: local
description: Team TypeScript conventions
appliesTo:
- "**/*.ts"
- "**/*.tsx"
# Path is resolved relative to this capabilities file.
path: rules/typescript.md
servers:
- id: brave
type: mcp
def:
cmd: npx -y @modelcontextprotocol/server-brave-search
env:
BRAVE_API_KEY: ${BraveApiKey}
tools:
- id: search
type: mcp
description: Search the web with Brave Search
def:
server: "@brave"
tool: brave_web_search
capa install
capa install resolves SHAs and downloads anything that isn't already in the cache. It then writes the per-provider files (.cursor/rules/, .claude/agents/, AGENTS.md, and so on) and registers one MCP endpoint with each agent on your list. The resolved SHAs land in capabilities.lock so the next clone gets the same bytes.
capa sh # list every configured tool
capa sh brave # list brave subcommands
capa sh brave search --query "…" # run a tool directly
Every tool you define is also a CLI command under capa sh. MCP tools live at capa sh <server> <tool>. Shell tools live at the top level (or under whatever group you assigned).
CAPA runs a local HTTP server (default 127.0.0.1:5912) for the web UI, REST API, and MCP endpoints.
When the server binds to a non-loopback address (anything other than 127.0.0.1, localhost, or ::1), all /api/* routes and MCP endpoints require authentication. Loopback-only bindings skip auth entirely.
Set a fixed token with the CAPA_AUTH_TOKEN environment variable. If unset on a non-loopback host, CAPA generates a random token at startup, saves it to ~/.capa/auth.token (mode 0600), and prints it once to stderr.
Clients must send the token via header (query-string tokens are rejecte