ClawHosters
von Daniel Samer
7 Min. Lesezeit
ClawHub hat im April 2026 die Marke von 44.000 Community Skills geknackt. Für eine Registry, die vor sechs Monaten noch nicht existierte, ist das ein irres Tempo. Aber was dir die meisten Tutorials verschweigen: Ein eigenes Skill zu bauen dauert ungefähr 10 Minuten. Vielleicht weniger.
Ein Skill ist ein Ordner mit einer SKILL.md Datei darin. Zwei YAML-Felder, ein paar Markdown-Anweisungen, fertig. Kein TypeScript, kein Build-Schritt, kein Framework. Wenn du einem Kollegen eine klare Anleitung schreiben kannst, kannst du auch ein OpenClaw Skill erstellen.
Ich zeige dir den kompletten Ablauf. Vom Bauen über das lokale Testen bis zur Veröffentlichung auf ClawHub.
Was in die SKILL.md gehört
Die offizielle OpenClaw Dokumentation beschreibt das Format ziemlich klar, aber die meisten Tutorials lassen die fortgeschrittenen Felder weg. Also hier das vollständige Bild.
Jede SKILL.md beginnt mit YAML Frontmatter zwischen --- Trennzeichen, gefolgt vom Markdown Body. Das Frontmatter sagt OpenClaw, was dein Skill ist. Der Markdown Body sagt dem Agent, was er tun soll.
---
name: deploy-checker
description: Verifies deployment health after pushing to production
version: 1.0.0
user-invocable: true
metadata: {"tags": ["devops", "deployment"], "homepage": "https://github.com/you/deploy-checker"}
---
Zwei Felder sind Pflicht: name und description. Alles andere ist optional, aber nützlich.
Ein paar Stolperfallen, die ich immer wieder sehe. Das metadata Feld muss einzeiliges JSON sein. Nicht mehrzeiliges YAML. Wenn du es über mehrere Zeilen schreibst, schlägt der Parser still fehl und deine Tags verschwinden einfach. Mindestens vier Entwickler sind damit in GitHub Issues auf die Nase gefallen. Einfach alles in eine Zeile packen.
Das Flag user-invocable: true macht dein Skill als Slash-Command verfügbar. Ohne dieses Flag kann der Agent das Skill trotzdem autonom nutzen, wenn es zur Anfrage passt, aber du kannst es nicht manuell auslösen. Setzt du stattdessen disable-model-invocation: true, bekommst du das Gegenteil: Ein Skill, das nur bei explizitem Aufruf läuft, nie autonom. Praktisch für Operationen, die etwas kaputt machen können.
Der Markdown Body
Hier bringst du dem Agent etwas bei. Stell dir das wie ein Runbook vor. Was soll der Agent tun? Welche Eingaben braucht er? Was sind die Schritte? Wie sieht guter Output aus?
Sei konkret. "Hilf dem User bei Deployments" ist eine schlechte Anweisung. "Prüfe den Health Endpoint unter /api/health nach jedem Deployment, berichte Status Code und Response Time, und melde alles über 2 Sekunden" ist eine gute.
Du kannst auch ein scripts/ Verzeichnis für Shell-Helfer und ein references/ Verzeichnis für Kontext-Dateien anlegen. Die meisten Skills brauchen das aber nicht.
Skills vs. Plugins: Wann brauche ich TypeScript?
Das v2026.5.18 Release brachte defineToolPlugin und drei CLI-Befehle (openclaw plugins build, validate, init) für einen separaten Plugin-Track.
Der Unterschied ist simpel. Skills sind Markdown-Anweisungen. Sie leiten den Agent in natürlicher Sprache an. Plugins sind TypeScript Code, der im Gateway-Prozess läuft und Zugriff auf interne APIs hat.
Nutze ein Skill, wenn du dem Agent einen Workflow beibringen, einen Prozess durchsetzen oder Fachwissen mitgeben willst. Nutze ein Plugin, wenn du deterministisches Verhalten brauchst, das du nicht dem Model überlassen kannst. Zum Beispiel einen neuen Channel registrieren oder einen Custom Provider verdrahten.
Ich schätze, dass 90 % der Anwendungsfälle ein Skill sein sollten. Plugins sind für die Fälle, in denen Natural Language Anweisungen an ihre Grenzen stoßen. Wenn du nicht sicher bist, was du brauchst: Fang mit einem Skill an.
Skills lokal testen
Leg deinen Skill-Ordner in ~/.openclaw/skills/ (global) oder .openclaw/skills/ in deinem Projekt (Workspace-Level). Workspace Skills überschreiben globale mit dem gleichen Namen.
Du hast drei Wege zum Testen:
Interaktiver Chat. Starte eine Konversation und schau, ob der Agent dein Skill erkennt. Bitte ihn, genau das zu tun, was dein Skill beschreibt. Wenn die Antwort stimmt, bist du auf dem richtigen Weg.
Slash Command. Wenn du user-invocable: true gesetzt hast, tipp einfach /deploy-checker (oder wie dein Skill heißt) direkt ein. Schnellere Feedback-Schleife, als darauf zu warten, dass der Agent von selbst matcht.
Headless CLI. Führe openclaw --skill deploy-checker --input "check staging" aus, um automatisiert ohne interaktive Session zu testen.
Ein Tipp, der viel Zeit spart: Aktiviere den Watcher mit skills.load.watch in deiner Config. Das hot-reloaded deine SKILL.md bei jedem Speichern. Ohne das musst du nach jeder Änderung den Daemon neu starten.
Wenn du eine ClawHosters Managed Instance betreibst, kannst du Skills direkt über das Dashboard installieren, ganz ohne CLI. Für die Entwicklung ist lokales Testen aber schneller.
Auf ClawHub veröffentlichen
Sobald dein Skill funktioniert, reicht ein einziger Befehl zum Veröffentlichen:
clawhub skill publish ./deploy-checker --slug deploy-checker --version 1.0.0
ClawHub lässt dein Skill durch VirusTotals Code Insight Scanning laufen. Du bekommst eins von drei Labels: Benign, Suspicious oder Malicious.
Jetzt der ehrliche Teil. Das Scanning erwischt weniger, als du hoffen würdest. Ein Nerdbot Audit von 1.024 Skills ergab, dass VirusTotal nur 4 von 177 bösartigen Skills erkannt hat (2,3 %). Das OpenClaw Team selbst nannte es "not a silver bullet". Das Scanning existiert also, aber Vertrauen innerhalb der Community basiert weiterhin darauf, dass Leute die SKILL.md vor der Installation tatsächlich lesen.
Wenn dein Skill Shell Commands, Dateizugriffe oder Netzwerk-Calls nutzt, rechne mit einem möglichen False Positive. Auch legitime Skills werden manchmal geflaggt. Dokumentiere in der SKILL.md selbst, warum dein Skill diese Berechtigungen braucht. Falls du geflaggt wirst: Nutze die Rescan-Funktion und warte auf das Maintainer Review.
Sicherheit: Jede SKILL.md wie ein Code Review behandeln
Im Januar 2026 fand Koi Security 341 bösartige Skills auf ClawHub. Das waren 11,9 % der gesamten Registry zu diesem Zeitpunkt. Das Angriffsmuster war clever: professionell aussehende Dokumentation mit "Prerequisites" Abschnitten, die User dazu brachten, vom Angreifer bereitgestellte Shell Commands auszuführen.
Als Skill-Autor stehst du auf der vertrauenswürdigen Seite. Aber du solltest wissen, wie die Lage aussieht, denn deine User werden vorsichtig sein. Sei transparent darüber, was dein Skill tut und warum. Wenn dein Skill exec Zugriff braucht, sag das von Anfang an und erkläre den Grund.
Für deine eigene Instance gilt das Gleiche, egal ob Self-Hosted oder auf ClawHosters: Installiere keine Skills blind. Lies die SKILL.md. Prüfe, welche Commands der Agent ausführen soll. Schau dir die Historie des Publishers an. Behandle es wie ein Code Review, denn genau das ist es.
