Plugin Sharing Research

Research: Sharing Claude Code Plugins with OpenClaw

Overview

This document explores how Claude Code plugins could be shared with an agent running on OpenClaw, enabling a unified capability set across both environments.

Architecture Comparison

Claude Code Plugins

Component	Location	Format
Commands	commands/*.md	Markdown with YAML frontmatter
Agents	agents/*.md	Markdown with YAML frontmatter
Skills	skills/<name>/SKILL.md	Markdown with YAML frontmatter
Hooks	hooks/hooks.json	JSON event handlers
MCP Servers	.mcp.json	Standard MCP config
Manifest	.claude-plugin/plugin.json	JSON metadata

Key Features:

• File-based, declarative configuration
• ${CLAUDE_PLUGIN_ROOT} for path resolution
• Automatic discovery of components
• Integration with Claude Code’s tool system

OpenClaw Skills/Extensions

Component	Location	Format
Skills	~/.openclaw/skills/<name>/SKILL.md	Markdown with YAML frontmatter
Plugins	extensions/	npm packages with package.json
Tool Registration	Via Plugin SDK	TypeBox schemas
Manifest	package.json with openclaw.extensions	npm-style with OpenClaw fields

Key Features:

• Four integration slots: channels, tools, memory, providers
• Tool policies and profiles (minimal, coding, messaging, full)
• Session and sender-based access control
• Gateway-level tool filtering

Common Ground

Both systems share important similarities that make integration feasible:

1. SKILL.md Format (Nearly Identical!)

Both use the same SKILL.md format with YAML frontmatter:

Claude Code:

---
description: Process PDF documents
---

# PDF Processor

Instructions for the skill...

OpenClaw:

---
name: pdf-processor
description: Process PDF documents
metadata:
  openclaw:
    emoji: "📄"
---

# PDF Processor

Instructions for the skill...

The only difference is OpenClaw uses additional metadata.openclaw fields.

2. MCP Server Support

Both systems support Model Context Protocol servers with similar configuration:

Claude Code (.mcp.json):

{
  "mcpServers": {
    "travel-hub": {
      "type": "http",
      "url": "https://your-mcp-server.example.com/mcp"
    }
  }
}

OpenClaw (openclaw.json):

{
  "mcp": {
    "servers": {
      "travel-hub": {
        "type": "http",
        "url": "https://your-mcp-server.example.com/mcp"
      }
    }
  }
}

3. Markdown-Based Agents

Both use markdown files for agent definitions with descriptive prompts.

Integration Approaches

Approach 1: Shared MCP Servers (Recommended - Immediate)

How it works: Both Claude Code and OpenClaw connect to the same MCP servers.

Implementation:

1. Deploy MCP servers (email, calendar, custom tools) as HTTP endpoints
2. Configure both systems to use the same MCP URLs
3. Tool capabilities are automatically available in both

Pros:

• Works today, no conversion needed
• Single source of truth for tool implementations
• Both systems get identical capabilities

Cons:

• Only covers MCP-based tools
• Doesn’t share skills/agents (the knowledge/prompts)

Approach 2: SKILL.md Converter Tool

How it works: Convert Claude Code skills to OpenClaw format (and vice versa).

Implementation:

# Hypothetical converter tool
openclaw-bridge convert \
  --from claude-code \
  --to openclaw \
  --input ~/GitHub/plugins/my-plugin/skills/ \
  --output ~/.openclaw/skills/

Pros:

• Reuses existing skill content
• One-time conversion, then native OpenClaw usage

Cons:

• Requires maintenance of converter
• May lose Claude Code-specific features

Approach 3: Unified Plugin Repository with Dual Entry Points

How it works: Single Git repo contains both Claude Code and OpenClaw configurations.

Structure:

plugins/
└── my-plugin/
    ├── .claude-plugin/plugin.json    # Claude Code manifest
    ├── package.json                   # OpenClaw manifest
    ├── skills/                        # Shared skills (SKILL.md format)
    │   └── filing-rules/SKILL.md
    ├── agents/                        # Shared agents
    │   └── inbox-triage.md
    └── .mcp.json                      # Shared MCP config

Pros:

• Single source of truth
• Git sync keeps both systems updated
• Minimal duplication

Cons:

• Complex setup
• Need adapter layer for OpenClaw

Approach 4: OpenClaw Bridge Skill

How it works: Create an OpenClaw skill that dynamically loads and executes Claude Code plugins.

Pros:

• Direct reuse without conversion
• Dynamic loading

Cons:

• Complex bridge implementation
• Performance overhead
• Potential compatibility issues

OpenClaw-Specific Considerations

Tool Policies

OpenClaw has sender-based tool policies that don’t exist in Claude Code:

{
  "tools": {
    "elevated": {
      "enabled": true,
      "allowFrom": {
        "bluebubbles": ["+1XXXXXXXXXX"]  // Owner only
      }
    }
  }
}

Implication: Some Claude Code plugins may have capabilities that should be restricted in OpenClaw based on who’s asking.

Session Scope

OpenClaw sessions can be per-sender or per-group, while Claude Code is per-project.

Implication: Plugin state management differs between systems.

Solution: Use MCP servers for shared state that persists across both systems.

Recommended Implementation Roadmap

Phase 1: Shared MCP Servers (Now)

• Already feasible for HTTP-based MCP servers
• Same data, different interfaces

Phase 2: Skill Converter (Short-term)

1. Build a simple converter for SKILL.md files
2. Convert existing Claude Code skills to OpenClaw format
3. Set up sync workflow to keep them in sync

Phase 3: Unified Repository (Medium-term)

1. Restructure plugin repos to support dual manifests
2. Create OpenClaw adapter layer
3. Test with pilot plugins

Phase 4: Deep Integration (Long-term)

1. Contribute to OpenClaw to improve Claude Code compatibility
2. Create ClawHub packages for public plugins
3. Build bidirectional sync tooling

Sources

• OpenClaw Extensions and Plugins - DeepWiki
• Claude Code Plugins Reference
• OpenClaw Official Documentation

Open Questions

1. Per-User Context: How should the agent differentiate the owner’s private sessions from family queries when using shared plugins?
2. State Synchronization: Should plugin state (e.g., filing rules, learned patterns) be shared between Claude Code and OpenClaw, or kept separate?
3. Tool Restrictions: Which Claude Code plugins should be restricted to elevated access in OpenClaw?
4. Update Workflow: When a plugin is updated in Claude Code, how should changes propagate to OpenClaw?