The Plugin Bundle Pattern Is Right. Nobody's Made It a Standard.

The interesting thing about Claude’s plugin system (custom commands, skills, MCPs bundled together) isn’t Claude’s implementation of it. It’s that the pattern itself is obviously correct, and nobody has made it a standard.

One install. Commands wired. Agent configured. Skills loaded. MCPs connected. The whole workflow just works. When I switched back to building in my own stack, I immediately started reaching for it.

I build on NanoClaw, which has its own skill and sub-agent system. The primitives are all there: MCP support, custom commands, sub-agents. But when I add a new capability to Buddy, say a new MCP server for some workflow, it’s still manual wiring. Add the server config. Write the skill description. Register the agent. Wire the commands. None of that is especially hard, but it’s work I’m doing from scratch every time. NanoClaw isn’t unique in this. No agent framework I’ve seen surfaces this as a first-class install-and-go experience. Compare that to a bundle: install it, and the commands, agents, and MCPs are already wired for that specific domain. The difference isn’t about code complexity. It’s about the cognitive overhead of assembly. A bundle assumes coherence. It ships opinions about how the pieces fit together.

Google does a version of this with Gemini extensions. Every platform that has thought seriously about composability has landed on some variant of this pattern. The primitives exist. What doesn’t exist is an open format that lets a bundle built once work across Claude, Gemini, and whatever else runs MCPs. The builder pays the cost of that gap every time they move between contexts. Right now that cost is just accepted. At some point it won’t be.