Why Can't We Agree on a Plugin Format? | Jason RobertI switch between coding assistants from time to time. Sometimes it’s Claude Code, sometimes it’s GitHub Copilot CLI, or occasionally I’m playing with OpenCode on a side project. Each one is good at different things, and I like having the option to switch between them.<br>What I don’t like is the tax I pay every time I move my own plugins between them.<br>The annoying part#<br>My plugins aren’t anything fancy. A handful of skills and agents, plus a few MCP servers here and there. Stuff I’ve built up over time and want available wherever I happen to be typing that day.<br>The problem is that every tool has its own packaging format:<br>Claude Code wants a .claude-plugin/ directory, a marketplace.json registry, and skill/agent markdown files with very specific frontmatter.<br>Copilot CLI wants a plugin.json manifest with its own schema, plus a .github/plugin/marketplace.json registry to be discoverable.<br>Codex CLI uses yet another layout under ~/.codex/.<br>OpenCode has no marketplace concept at all. Each plugin is just files you drop into a project’s .opencode/ folder.<br>The differences are small on their own (a field gets renamed in one tool, a directory moves in another, frontmatter keys swap around), but copy-pasting one plugin into the layout another tool expects still takes about fifteen minutes of fiddly editing every time. And I have to do it again on each of my dev machines. Multiply by a few plugins and the friction adds up fast… and then when I want to switch back… well, you get the idea.<br>What other people are doing#<br>Before I built anything, I poked around to see how other people were solving this. There’s a fair bit going on, but most of it didn’t directly address my problem.<br>The biggest projects in this space are large skills libraries that handle the cross-tool install for you. alirezarezvani/claude-skills and borghei/Claude-Skills both ship hundreds of SKILL.md files plus install scripts (./scripts/convert.sh --tool all, npx @borghei/claude-skills add ...) that drop the right thing into each tool’s expected directory. They cover 9–11 assistants between them and they clearly work, which is why they have thousands of stars. The catch is they’re skills-only. A skill is one thing in a plugin. Agents, MCP server configs, hooks, slash commands, and the marketplace registry that tells /plugin install what’s available are different things, and those libraries don’t handle them. They also assume Claude’s SKILL.md schema as the canonical source and convert outward, which is fine until you want to author in a tool-neutral format.<br>Happier is a companion app that treats your prompt/skill library as the source of truth and exports it to provider-native locations on each machine. It’s a thoughtful approach if you want a long-lived app managing your library, but again the surface is prompts and skills, not full plugin bundles.<br>A few people are reaching for symlinks , keeping one master file and linking it into each tool’s expected path. That only solves the case where the files are identical across tools. But a lot of the providers have different frontmatter requirements, and some have fields the others don’t support.<br>These are all really cool projects. They just don’t solve the specific thing I was hitting: I wanted to author a complete plugin (skills, agents, hooks, MCP, plus the marketplace metadata) once, and let each tool’s native /plugin install flow consume it without me hand-editing four versions every time something changed.<br>The template repo#<br>plugin-marketplace-template is a GitHub template repository I created to help eliminate some of this toil. You click “Use this template,” get your own copy, and that copy is a working plugin marketplace from day one. It’s a template because it doesn’t actually contain any plugins, just the scaffolding to make it easy to add your own and keep them in sync across tools.<br>You author each plugin once:<br>plugins//<br>plugin.yaml # declarative manifest, with per-target overrides<br>agents/.md # body only, no frontmatter<br>skills//SKILL.md # body only<br>.mcp.json # optional<br>hooks/hooks.json # optional
Then npm run build runs a small Node transpiler that produces:<br>dist/claude// → Claude Code plugin<br>dist/copilot// → Copilot CLI plugin<br>dist/codex// → Codex CLI plugin<br>dist/opencode// → OpenCode bundle
…and regenerates the per-tool marketplace registries (.claude-plugin/marketplace.json, .github/plugin/marketplace.json) so each assistant’s /plugin install flow just works.<br>The dist/ directory is committed on purpose. The generated marketplace files point at ./dist// as the plugin source, and the tools resolve those paths over the remote git tree. So the downstream loop is: edit plugins/, run npm run build, commit both, push. That’s the whole workflow.<br>Adding a fifth target later (Gemini CLI, Cursor,...