One Registry to Rule Them All

I had 67 skills scattered across four different systems. Claude Code had its own. OpenClaw had its own. MCP servers lived in their own config files. CLI scripts were just… floating.

No single place told me what I could do. No way to know if two tools overlapped. No way for a new orchestrator to discover what was available.

So I built a unified skill registry. Here’s why — and how.

The Problem: Skill Sprawl

When you build agents long enough, you accumulate capabilities like a junk drawer accumulates batteries. Each system has its own way of registering and discovering tools:

Claude Code knows about MCP servers in ~/.claude.json
OpenClaw has skills in ~/clawd/skills/ and agents in ~/clawd/agents/
CLI engines are Python/Node scripts invoked by path
AI-OS modules are cron-driven Python modules

None of these systems talk to each other. Your Claude Code session can’t use an OpenClaw skill. Your OpenClaw agent can’t call an MCP server directly. It’s fragmented.

Pattern B: Central Registry

After deep research into integration patterns, we landed on Pattern B — a central YAML manifest that maps every skill to its backend, regardless of where it lives.

# skills-registry.yaml (simplified)
skills:
  - name: gmail
    tier: 1  # MCP Server
    backend: mcp
    server: email-gmail
    tools: [get_inbox, search_messages, send_message]

  - name: pptx-elite
    tier: 2  # OC Skill
    backend: oc-skill
    path: ~/clawd/skills/pptx-elite

  - name: researcher
    tier: 3  # CLI Engine
    backend: cli
    command: python3.12 -m agents.researcher.main

  - name: health-coach
    tier: 4  # AI-OS Module
    backend: module
    path: ~/agent-system/modules/health/

Why YAML?

Three reasons:

Human-readable. You can scan 67 skills in 30 seconds.
Git-trackable. Every addition is a diff.
Machine-parseable. Any orchestrator can load it — Python, Node, Rust, whatever comes next.

We considered a database. Overkill. We considered JSON. Too noisy for 67 entries. YAML hits the sweet spot.

Auto-Registration

The registry is only useful if it stays current. So we hooked into our scaffold tools:

# When you create a new skill
$ python new_skill.py "deck-builder"
# → Creates skill files
# → Auto-appends to skills-registry.yaml
# → Validates no name conflicts

Same for new_agent.py and new_mcp_server.py. Create something new, it shows up in the registry automatically.

The Multi-Orchestrator Future

Here’s the real insight: your orchestrator should be swappable.

Today I use Claude Code as my primary orchestrator via Telegram. But OpenClaw can also orchestrate. Tomorrow it might be a custom Rust agent, or a voice-first orchestrator, or something that doesn’t exist yet.

With a unified registry, switching orchestrators is trivial. The new system reads skills-registry.yaml, discovers 67 capabilities, and starts routing. No migration. No rewriting tool configs.

The skills are the product. The orchestrator is just a frontend.

What We Learned

Start the registry early. Retrofitting 67 skills is painful. Start with 5.
Validate continuously. We run a script that checks the registry against live configs and flags orphans.
Tier your skills. Not all skills are equal. MCP servers (Tier 1) are always-on. CLI engines (Tier 3) are on-demand. The tier tells the orchestrator how to invoke them.
Don’t centralize execution. The registry is a map, not a runtime. Skills run where they run.

The full registry pattern is open source. Follow on LinkedIn for updates on multi-orchestrator architecture.