SkillClaw: eine gemeinsame Skill-Bibliothek für Hermes, OpenClaw und verwandte Agenten

Das Problem: verstreute Skill-Bibliotheken statt fehlender Skills

Das README formuliert die Ausgangslage ungewöhnlich direkt: Das Problem sei nicht, dass Hermes zu wenig lerne, sondern dass niemand helfe, das Gelernte zu verdauen. Als Symptome nennt der Text Duplikate, veraltete und halbfertige Skills, die sich in einer ungeordneten Bibliothek stapeln. Der Adressat ist damit klar umrissen: Nutzer, die einen oder mehrere Agenten über längere Zeit betreiben und deren Skill-Bestand wachsen lassen, ohne ihn zu pflegen. SkillClaw setzt nicht beim Aufgabenlauf an, sondern danach. Es verspricht Auto-Evolve, Auto-Deduplizierung und Qualitätsverbesserung, ohne den Arbeitsablauf zu unterbrechen. Der zweite Adressatenkreis sind Teams: Sobald mehrere Personen dieselbe Gruppe teilen, sollen deren Erfahrungen in dieselbe Schleife einfließen. Das ist eine soziale Behauptung, keine technische, und sie hängt vollständig daran, wie eine solche Gruppe zustande kommt. Dazu sagt das vorliegende Material nichts.

Zwei Schleifen: Aufgabenzeit und Nachbereitung

Die Architekturdarstellung im README unterscheidet zwei Schleifen. Die erste ist der normale Aufgabenlauf des Agenten, in dem ein Skill angewendet wird. Die zweite läuft nach der Aufgabe und verändert den Skill-Bestand. Diese Trennung ist der eigentliche Entwurfsgedanke: Skill-Evolution wird nicht in den kritischen Pfad der Aufgabenbearbeitung gelegt, sondern daneben. Der Daemon, gestartet mit skillclaw start --daemon, ist die Instanz, die diese zweite Schleife am Leben hält. Das README zeigt außerdem ein Ablaufdiagramm, in dem ein Skill über mehrere Nutzer hinweg evolviert. Der Text beschreibt das Ergebnis mit der Formulierung, dass ein Nutzer ein Datenbankproblem debuggt, der Skill sich weiterentwickelt und die übrigen Nutzer davon profitieren, ohne auf dasselbe Problem zu stoßen. Wie ein Skill zwischen zwei Agenten oder zwei Rechnern transportiert wird, ob über ein gemeinsames Verzeichnis, einen Dienst oder eine Datenbank, geht aus dem Material nicht hervor. Genau diese Frage ist aber die interessanteste, weil sie über Datenschutz und Betriebsaufwand entscheidet.

Installation: Shell-Installer, dann setup und Daemon

Der Einstieg ist knapp dokumentiert. Für macOS und Linux nennt das README einen Shell-Installer, für Windows einen manuellen Python-Pfad. Python 3.10 oder neuer wird vorausgesetzt. Danach folgen zwei Befehle, die im README als Terminal-Grafik eingebettet sind: skillclaw setup und skillclaw start --daemon. Der erste richtet die Umgebung ein, der zweite startet den Hintergrundprozess, der die Nachbereitungsschleife ausführt. Später im Text taucht zusätzlich skillclaw dashboard sync auf, eingeführt zusammen mit einem zweisprachigen Dashboard. Das ist bemerkenswert, weil es bedeutet, dass der Daemon nicht die einzige Komponente ist: Es gibt einen Dashboard-Zustand, der synchronisiert werden muss. Ob dashboard sync gegen eine lokale Datei, einen Server oder eine Gruppe arbeitet, sagt das Material nicht. Wer SkillClaw produktiv einsetzen will, sollte diesen Punkt vor der Installation klären, weil er bestimmt, welche Netzwerkziele der Daemon erreichen muss.

Kompatibilität ist der stärkste Teil des Angebots

Das README listet eine breite Palette von Integrationen: Hermes, Codex, Claude Code, OpenClaw, QwenPaw, IronClaw, PicoClaw, ZeroClaw, NanoClaw und NemoClaw, dazu jede OpenAI-kompatible API. Das ist mehr als Marketing, denn es legt eine Architekturentscheidung offen. Wenn SkillClaw mit so unterschiedlichen Agenten zusammenarbeiten soll, kann die Anbindung nicht an einem internen Skill-Format eines einzelnen Agenten hängen. Entweder normalisiert SkillClaw die Formate, oder es arbeitet auf einer gemeinsamen Abstraktion, die alle genannten Agenten bereits verwenden. Das Material lässt beide Möglichkeiten offen und nennt kein Skill-Schema, keine Dateiendung und kein Verzeichnis, in dem Skills liegen. Für eine Adoption ist das die wichtigste offene Frage überhaupt, weil sie bestimmt, ob ein vorhandener, handgeschriebener Skill-Bestand übernommen wird oder ob er neu aufgebaut werden muss.

Wo SkillClaw das falsche Werkzeug ist

Der Nutzen von SkillClaw skaliert mit der Anzahl der Quellen. Ein einzelner Agent auf einem einzelnen Rechner hat nichts zu deduplizieren und nichts zu verteilen. Das README beschreibt diesen Fall zwar, aber der Gewinn liegt dort in der Qualitätsverbesserung einzelner Skills, nicht im Zusammenführen. Wer reproduzierbare Ergebnisse braucht, sollte ebenfalls vorsichtig sein: Ein System, das Skills im Hintergrund verändert, verschiebt das Verhalten des Agenten zwischen zwei Läufen, ohne dass ein Commit oder eine Review stattfindet. Das README nennt keine Möglichkeit, eine Änderung abzulehnen, zu versionieren oder zurückzurollen. Für Umgebungen mit Audit-Anforderungen ist das ein Ausschlusskriterium, solange diese Funktionen nicht nachgewiesen sind. Ein dritter Grenzfall ist der Datenschutz: Sobald mehrere Nutzer in derselben Gruppe arbeiten, wandern Erfahrungen aus einer Sitzung in den gemeinsamen Bestand. Ob dabei Prompt-Inhalte, Code oder nur abstrahierte Regeln übertragen werden, ist aus dem Material nicht erkennbar.

Alternative: Skills von Hand pflegen

Die realistische Alternative ist der heutige Zustand, also ein von Hand gepflegtes Skill-Verzeichnis, das im Repository des Teams liegt und über Code-Review geändert wird. Der Unterschied liegt nicht in der Funktion, sondern im Zeitpunkt und in der Kontrolle. Handarbeit ändert Skills vor dem Einsatz, mit einem Diff, einem Reviewer und einer Historie. SkillClaw ändert sie nach dem Einsatz, automatisch und ohne dass jemand zustimmt. Der eine Ansatz ist langsam und nachvollziehbar, der andere schnell und undurchsichtig. Für einen einzelnen Entwickler mit einem Agenten ist der manuelle Weg oft ausreichend und deutlich billiger. Interessant wird SkillClaw erst, wenn die Zahl der Agenten und Geräte so groß wird, dass Handarbeit nicht mehr hinterherkommt. Dann ist die Frage nicht mehr, ob Automatik besser ist, sondern ob der Verlust an Nachvollziehbarkeit durch den Gewinn an Abdeckung aufgewogen wird.

Wartung, Lizenz und was vor dem Einsatz zu klären ist

Das Repository steht unter MIT. Das ist die permissivste gängige Variante: Nutzung, Änderung und Weitergabe sind erlaubt, sofern der Copyright-Hinweis und der Lizenztext beibehalten werden. Für eine kommerzielle Nutzung ist das unproblematisch, und es besteht keine Copyleft-Pflicht, den eigenen Code offenzulegen. Das gilt für den Code, den das Repository enthält. Ob Skills, die durch den Evolutionsprozess entstehen, eigenständige Werke sind und wem sie gehören, regelt die MIT-Lizenz nicht, und das Material sagt dazu nichts. Wartungskosten entstehen an zwei Stellen. Erstens läuft mit skillclaw start --daemon ein dauerhafter Prozess, der überwacht werden will. Zweitens wächst der Skill-Bestand weiter, und das README nennt keine Obergrenze, keine Größenschwelle und keinen Modus, in dem die Evolution pausiert. Die letzte Aktualisierung des Repositories liegt laut Metadaten im August 2026. Releases wurden nicht abgerufen, es gibt also keine veröffentlichte Versionsnummer, an der man sich orientieren könnte. Vor einem Einsatz würde ich deshalb zuerst prüfen, ob die installierte Version die im README gezeigten Unterbefehle tatsächlich kennt und ob dashboard sync ohne konfigurierte Gruppe überhaupt ein sinnvolles Ergebnis liefert.

Redaktionelles Fazit

SkillClaw passt zu Nutzern, die bereits mehrere Hermes-, OpenClaw- oder kompatible Agenten-Instanzen betreiben und deren Skill-Bibliotheken zusammenführen wollen. Wer nur einen Agenten auf einem Rechner nutzt, gewinnt wenig, weil es dann nichts zu deduplizieren und nichts zu verteilen gibt. Vor dem Einsatz würde ich zuerst prüfen, ob der Daemon ohne einen Gruppen-Endpunkt überhaupt sinnvoll arbeitet, ob die Dashboard-Synchronisation ohne konfigurierte Gruppe funktioniert und ob die installierte Version zu den im README gezeigten Unterbefehlen passt.

Offizielle Quellen

1. AMAP-ML/SkillClaw on GitHub
2. Issues
3. License: MIT
4. README