The plugin marketplace model has a seductive pitch: install what you need, skip what you don't, contribute your own. It worked for browsers, for VS Code, for WordPress. It seemed natural to apply the same model to AI agents. Then ClawHub happened — 41.7% of published skills contained vulnerabilities, hundreds were outright malicious, and the entire trust model collapsed under the weight of a supply chain that nobody could audit.
NanoClaw looked at that failure and asked a different question: what if extensibility didn't require a marketplace at all? What if adding a new capability to your AI assistant was as simple as telling Claude Code what you wanted, and having it modify the source code directly?
That's the Claude Code skills model. And it turns out to be both simpler and more secure than any plugin system.
How Skills Actually Work
A Claude Code skill is a slash command — like /add-telegram or /add-discord — that you run inside a Claude Code session. When you invoke a skill, Claude Code reads the NanoClaw source code, understands the existing architecture, and writes the new integration directly into the codebase. It's not installing a package from a registry. It's not downloading code from the internet. It's generating code that fits your specific NanoClaw instance, reviewed by you before it runs.
The /add-telegram skill, for example, doesn't install a Telegram npm package and wire it up through a plugin interface. It adds a Telegram bot listener to NanoClaw's message loop, using the node-telegram-bot-api library, with the same container isolation and security model that WhatsApp already uses. The generated code follows the same patterns as the existing codebase because Claude Code can see the existing codebase and match its style.
This is fundamentally different from a plugin system in three ways. First, the code is visible. You can read every line that was added, understand what it does, and modify it if you want. There's no compiled binary, no minified bundle, no opaque package that you're trusting blindly. Second, the code is local. It lives in your repository, under your version control, subject to your review process. It doesn't phone home, doesn't auto-update, doesn't change behavior without your knowledge. Third, the code is integrated. It's not running in a separate plugin sandbox with a limited API — it's part of the application, with full access to the patterns and utilities that the rest of the codebase uses.
Why This Is More Secure Than Plugins
The security argument is straightforward, but it's worth spelling out because it's the opposite of what most developers expect.
In a plugin system, security depends on trust. You trust the plugin author, you trust the marketplace's review process, you trust that the package hasn't been compromised since it was reviewed, and you trust that its dependencies haven't been compromised either. Each of these trust assumptions is a potential failure point, and ClawHub demonstrated that all of them can fail simultaneously.
In the skills model, security depends on visibility. When Claude Code generates a Telegram integration, you can see exactly what it does before you run it. You can review the code, test it, modify it, or reject it entirely. The trust boundary isn't "do I trust this unknown developer's npm package?" — it's "does this code that I can read do what I want it to do?"
There's also no supply chain to attack. A malicious actor can't upload a trojanized skill to a marketplace because there is no marketplace. They can't typosquat a popular package name because there are no packages. The attack surface that enabled hundreds of malicious ClawHub skills simply doesn't exist in this model.
The trade-off is that skills require Claude Code to generate them, which means you need an Anthropic API key and a Claude Code session. You can't browse a catalog and click "install." But for a project whose users are developers comfortable with a CLI, this trade-off is barely noticeable — and the security benefits are substantial.
The Skills That Exist Today
NanoClaw ships with WhatsApp built in. Everything else is added through skills. The current skill set covers the most requested integrations: /add-telegram for Telegram bot support, /add-discord for Discord gateway integration, /add-slack for Slack Events API, and /add-signal for Signal messaging.
Each skill generates roughly 100-300 lines of code, depending on the complexity of the channel's API. The generated code includes the channel listener, message formatting, container routing, and configuration — everything needed for the integration to work end-to-end. It also includes the environment variable declarations and setup instructions, so you know exactly what tokens and credentials you need to provide.
Beyond channel integrations, skills can add tools and capabilities. A /add-web-search skill could add a web search tool that agents can use inside containers. A /add-calendar skill could integrate with Google Calendar for scheduling. The pattern is the same: Claude Code reads the codebase, understands the architecture, and generates code that fits.
The Fork-Friendly Philosophy
There's a deeper philosophy behind the skills model that's worth articulating. NanoClaw is designed to be forked. Not in the hostile sense of "take the code and compete" — in the collaborative sense of "take the code and make it yours."
When you run /add-telegram, you're not installing a dependency that ties you to NanoClaw's release cycle. You're adding code to your fork that you own completely. If NanoClaw's upstream changes in a way you don't like, your Telegram integration still works. If you want to modify how Telegram messages are formatted, you edit the code directly — no plugin API limitations, no waiting for the upstream to expose a new hook.
This is the opposite of the platform lock-in that plugin marketplaces create. WordPress plugins tie you to WordPress. VS Code extensions tie you to VS Code. ClawHub skills tied you to OpenClaw. NanoClaw skills generate plain TypeScript that happens to work with NanoClaw's architecture but doesn't depend on any plugin runtime or marketplace infrastructure.
The result is a project that gets more capable over time — not because a marketplace grows, but because each user's fork accumulates exactly the capabilities they need, generated by an AI that understands the codebase well enough to extend it correctly. It's extensibility through understanding, not through abstraction.