Summary

Skillshare already acts as a single source of truth for skills, agents, and extras across many AI CLIs. I’d like to propose adding plugin support as a first-class resource type, so users can import, normalize, and sync plugin content between tools such as Codex and Claude Code, instead of manually re-creating the same workflows in each ecosystem.

Problem

Today, plugin ecosystems are becoming an important distribution mechanism for reusable AI workflows:

• Codex plugins can bundle workflows, bundled skills, and MCP-related setup.
• Claude Code plugins can include skills, agents, hooks, MCP servers, and other plugin-specific components.

Skillshare currently solves “one source, many targets” for skills/agents/extras very well, but plugins still sit outside that model. That creates a few problems:

1. A useful plugin installed in one tool is often not portable to another.
2. Shared functionality (skills, agents, MCP config, commands) gets duplicated manually.
3. Teams lose a canonical source of truth once they move from raw skills into richer plugin packaging.
4. Migration between ecosystems becomes harder than it should be.

Proposal

Introduce plugins as a new resource kind in skillshare, alongside skills, agents, and extras.

High-level idea

Skillshare would provide a canonical intermediate model for plugin contents, then map that model to each target’s native format.

That means skillshare could:

• Import plugin contents from supported ecosystems
• Normalize overlapping concepts into a common internal representation
• Sync/export them back out into target-specific layouts

Example use cases

• Import a Claude Code plugin and sync the compatible parts into Codex
• Import a Codex plugin and sync the compatible parts into Claude Code
• Keep one repo as the source of truth and generate per-tool plugin layouts
• Reuse bundled skills/agents/MCP config across multiple AI CLIs without maintaining separate copies

Suggested scope

Phase 1: Read/import plugin contents

Support importing plugin folders/manifests from at least:

• Claude Code plugins
• Codex plugins

Imported components could be mapped into a canonical model such as:

• skills
• agents
• commands
• MCP servers/config
• metadata
• optional tool-specific extensions

Phase 2: Sync/export to targets

Allow syncing compatible plugin content into target-native layouts.

Example behavior:

• supported components are rendered normally
• unsupported components are skipped with a clear warning/report
• target-specific metadata is preserved where possible

Phase 3: Optional marketplace/index support

If skillshare continues growing as a hub/index-based system, plugin metadata could later be searchable/installable in a similar way to skills.

CLI ideas

Some possible commands:

skillshare sync plugins
skillshare import plugin /path/to/plugin
skillshare install plugin <source>
skillshare list plugins
skillshare check plugins
skillshare audit plugins