Capabilities Registry

What It Is

The Capabilities Registry is the inventory layer of the Agentic Work System. It tracks every capability available across agents — 71 entries spanning agents, plugins, skills, and MCP tools — with structured metadata: source (internal, Anthropic, community), quality score, tags, description, and which clients have it enabled.

The registry is the answer to “what can this system actually do?” without digging through configuration files.

Structure

Each capability is a capability.yaml manifest — the source of truth. Everything else is derived:

capability.yaml → generate-inventory.sh → inventory.json → INVENTORY.md

INVENTORY.md and inventory.json are never hand-edited. The scripts regenerate them from the manifests. This keeps the catalog honest — if it’s in the inventory, there’s a real manifest behind it.

Capabilities live in four directories:

capabilities/
├── agents/     # Sub-agent definitions
├── plugins/    # Composite packages (skills + hooks + commands)
├── skills/     # SKILL.md-based procedural knowledge
└── tools/      # MCP servers, deterministic scripts

Declined candidates go into declined.yaml rather than being deleted — so evaluation history is preserved. Deprecated capabilities move to archive/ rather than disappearing.

Lifecycle

inbox → staging → capabilities/<type>/ → archive/

New capabilities enter staging for evaluation before promotion to active. The scripts/promote.sh script handles the move. Freshness checks flag entries that haven’t been updated recently.

Connection to ADF MCP

The ADF MCP server exposes query_capabilities — a tool that lets agents discover what’s available before committing to a plan. This makes capability assessment a first-class step in planning rather than an assumption baked into agent prompts.

The planner agent uses it explicitly: before generating a task decomposition, it checks whether the capabilities required to execute the plan actually exist. Missing capabilities surface as blockers, not surprises.

Cross-Client Enablement

The registry tracks which clients have each capability enabled — Claude Code, Claude Desktop, Codex, Gemini CLI. Of the 71 current capabilities, all 71 are enabled in Claude Code. Other clients get a subset based on what’s relevant and tested.

Installer scripts handle the mechanical work of wiring MCP servers into each client’s config, with dry-run mode by default so the generated commands can be inspected before applying.

Why It Exists

Without a registry, capability knowledge lives in someone’s head or in scattered config files. The registry makes it explicit, queryable, and auditable. When a new agent is built, it can discover what tools are available rather than having them hardcoded. When a capability is deprecated, there’s a record of why.

It’s a small piece of infrastructure, but it’s the piece that makes the rest of the system discoverable.