Das Plugin-Marktplatz-Modell hat ein verführerisches Versprechen: Installiere, was du brauchst, überspringe, was du nicht brauchst, steuere eigenes bei. Es funktionierte für Browser, für VS Code, für WordPress. Es schien naheliegend, dasselbe Modell auf KI-Agents anzuwenden. Dann kam ClawHub — 41,7 % der veröffentlichten Skills enthielten Schwachstellen, Hunderte waren schlicht bösartig, und das gesamte Vertrauensmodell brach unter dem Gewicht einer Supply Chain zusammen, die niemand auditieren konnte.
NanoClaw betrachtete dieses Scheitern und stellte eine andere Frage: Was, wenn Erweiterbarkeit gar keinen Marktplatz erfordert? Was, wenn das Hinzufügen einer neuen Fähigkeit zum KI-Assistenten so einfach wäre wie Claude Code zu sagen, was man will, und es den Quellcode direkt ändern zu lassen?
Das ist das Claude Code Skills-Modell. Und es erweist sich als sowohl einfacher als auch sicherer als jedes Plugin-System.
Wie Skills tatsächlich funktionieren
Ein Claude Code Skill ist ein Slash-Befehl — wie /add-telegram oder /add-discord — den man in einer Claude Code-Sitzung ausführt. Wenn man einen Skill aufruft, liest Claude Code den NanoClaw-Quellcode, versteht die bestehende Architektur und schreibt die neue Integration direkt in die Codebasis. Es installiert kein Paket aus einer Registry. Es lädt keinen Code aus dem Internet herunter. Es generiert Code, der zu der spezifischen NanoClaw-Instanz passt, von dir geprüft, bevor er ausgeführt wird.
Der /add-telegram Skill zum Beispiel installiert kein Telegram-npm-Paket und verdrahtet es über ein Plugin-Interface. Er fügt einen Telegram-Bot-Listener zu NanoClaws Nachrichtenschleife hinzu, unter Verwendung der node-telegram-bot-api-Bibliothek, mit demselben Container-Isolations- und Sicherheitsmodell, das WhatsApp bereits nutzt. Der generierte Code folgt denselben Mustern wie die bestehende Codebasis, weil Claude Code die bestehende Codebasis sehen und ihren Stil nachahmen kann.
Das unterscheidet sich grundlegend von einem Plugin-System in drei Punkten. Erstens: Der Code ist sichtbar. Man kann jede hinzugefügte Zeile lesen, verstehen, was sie tut, und sie bei Bedarf ändern. Kein kompiliertes Binary, kein minifiziertes Bundle, kein undurchsichtiges Paket, dem man blind vertraut. Zweitens: Der Code ist lokal. Er lebt im eigenen Repository, unter der eigenen Versionskontrolle, unterliegt dem eigenen Review-Prozess. Er telefoniert nicht nach Hause, aktualisiert sich nicht automatisch, ändert sein Verhalten nicht ohne Wissen des Nutzers. Drittens: Der Code ist integriert. Er läuft nicht in einer separaten Plugin-Sandbox mit einer eingeschränkten API — er ist Teil der Anwendung, mit vollem Zugriff auf die Muster und Utilities, die der Rest der Codebasis nutzt.
Warum das sicherer ist als Plugins
Das Sicherheitsargument ist geradlinig, aber es lohnt sich, es auszubuchstabieren, weil es das Gegenteil dessen ist, was die meisten Entwickler erwarten.
In einem Plugin-System hängt Sicherheit von Vertrauen ab. Man vertraut dem Plugin-Autor, man vertraut dem Review-Prozess des Marktplatzes, man vertraut darauf, dass das Paket seit dem Review nicht kompromittiert wurde, und man vertraut darauf, dass seine Abhängigkeiten ebenfalls nicht kompromittiert wurden. Jede dieser Vertrauensannahmen ist ein potenzieller Fehlerpunkt, und ClawHub hat gezeigt, dass alle gleichzeitig versagen können.
Im Skills-Modell hängt Sicherheit von Sichtbarkeit ab. Wenn Claude Code eine Telegram-Integration generiert, kann man genau sehen, was sie tut, bevor man sie ausführt. Man kann den Code reviewen, testen, ändern oder komplett ablehnen. Die Vertrauensgrenze ist nicht „Vertraue ich dem npm-Paket dieses unbekannten Entwicklers?" — sondern „Tut dieser Code, den ich lesen kann, das, was ich will?"
Außerdem gibt es keine Supply Chain, die angegriffen werden kann. Ein bösartiger Akteur kann keinen trojanisierten Skill in einen Marktplatz hochladen, weil es keinen Marktplatz gibt. Er kann keinen populären Paketnamen per Typosquatting kapern, weil es keine Pakete gibt. Die Angriffsfläche, die Hunderte bösartiger ClawHub-Skills ermöglichte, existiert in diesem Modell schlicht nicht.
Der Kompromiss ist, dass Skills Claude Code erfordern, um sie zu generieren, was bedeutet, dass man einen Anthropic API-Key und eine Claude Code-Sitzung braucht. Man kann nicht durch einen Katalog browsen und auf „Installieren" klicken. Aber für ein Projekt, dessen Nutzer Entwickler sind, die mit einem CLI vertraut sind, ist dieser Kompromiss kaum spürbar — und die Sicherheitsvorteile sind erheblich.
Die Skills, die es heute gibt
NanoClaw wird mit eingebautem WhatsApp ausgeliefert. Alles andere wird über Skills hinzugefügt. Das aktuelle Skill-Set deckt die am häufigsten nachgefragten Integrationen ab: /add-telegram für Telegram-Bot-Unterstützung, /add-discord für Discord-Gateway-Integration, /add-slack für die Slack Events API und /add-signal für Signal-Messaging.
Jeder Skill generiert ungefähr 100–300 Zeilen Code, abhängig von der Komplexität der Kanal-API. Der generierte Code umfasst den Kanal-Listener, die Nachrichtenformatierung, das Container-Routing und die Konfiguration — alles, was für eine End-to-End-funktionierende Integration nötig ist. Er enthält auch die Umgebungsvariablen-Deklarationen und Setup-Anweisungen, sodass man genau weiß, welche Tokens und Zugangsdaten man bereitstellen muss.
Über Kanal-Integrationen hinaus können Skills Tools und Fähigkeiten hinzufügen. Ein /add-web-search Skill könnte ein Websuche-Tool hinzufügen, das Agents in Containern nutzen können. Ein /add-calendar Skill könnte Google Calendar für die Terminplanung integrieren. Das Muster ist dasselbe: Claude Code liest die Codebasis, versteht die Architektur und generiert Code, der passt.
Die Fork-freundliche Philosophie
Hinter dem Skills-Modell steckt eine tiefere Philosophie, die es wert ist, artikuliert zu werden. NanoClaw ist darauf ausgelegt, geforkt zu werden. Nicht im feindlichen Sinne von „nimm den Code und konkurriere" — im kollaborativen Sinne von „nimm den Code und mach ihn zu deinem".
Wenn man /add-telegram ausführt, installiert man keine Abhängigkeit, die einen an NanoClaws Release-Zyklus bindet. Man fügt Code zum eigenen Fork hinzu, den man vollständig besitzt. Wenn sich NanoClaws Upstream in eine Richtung ändert, die einem nicht gefällt, funktioniert die Telegram-Integration trotzdem. Wenn man ändern möchte, wie Telegram-Nachrichten formatiert werden, bearbeitet man den Code direkt — keine Plugin-API-Einschränkungen, kein Warten darauf, dass der Upstream einen neuen Hook freigibt.
Das ist das Gegenteil des Plattform-Lock-ins, den Plugin-Marktplätze erzeugen. WordPress-Plugins binden an WordPress. VS Code-Extensions binden an VS Code. ClawHub-Skills banden an OpenClaw. NanoClaw-Skills generieren reines TypeScript, das zufällig mit NanoClaws Architektur funktioniert, aber nicht von einer Plugin-Runtime oder Marktplatz-Infrastruktur abhängt.
Das Ergebnis ist ein Projekt, das mit der Zeit leistungsfähiger wird — nicht weil ein Marktplatz wächst, sondern weil jeder Fork des Nutzers genau die Fähigkeiten ansammelt, die er braucht, generiert von einer KI, die die Codebasis gut genug versteht, um sie korrekt zu erweitern. Es ist Erweiterbarkeit durch Verständnis, nicht durch Abstraktion.