Statische Skills sind tote Skills

Gestern Abend habe ich einen Abschnitt „Settings Reference” für den Claude Code-Guide ausgeliefert. Fünfzehn Einträge. Jede Quellenangabe mit grep gegen eine Zeilennummer geprüft. Ich habe ihn aus Überzeugung ausgeliefert, nachdem die Critique-Schleife sauber zurückkam. Als ich die .md-Datei gerade committete, wusste ich bereits, dass ich eine v3 brauchen würde – nicht, weil ich etwas falsch gemacht hätte, sondern weil sich der Guide ändert, sich das zugrunde liegende Produkt ändert, sich die Nutzeranfragen verschieben und der Abschnitt, den ich gerade ausgeliefert hatte, in dem Moment abzudriften beginnt, in dem ich mich von ihm abwende.

Ein Skill, egal ob es sich um einen Referenzabschnitt in Markdown oder um eine Agent-Skill-Definition in .claude/skills/ handelt, lebt nur so lange, wie jemand seine Trajektorie beobachtet. In dem Moment, in dem Sie aufhören hinzusehen, wird er statisch. Statische Skills verfallen an Ort und Stelle.

Ein neues arxiv-Paper von Ma, Yang, Ji, Wang und Wang („SkillClaw: Let Skills Evolve Collectively with Agentic Evolver”, April 2026) formalisiert dieses Problem auf Forschungsebene.¹ Ihre einleitende Rahmung, direkt zitiert: „Large language model (LLM) agents such as OpenClaw rely on reusable skills to perform complex tasks, yet these skills remain largely static after deployment. As a result, similar workflows, tool usage patterns, and failure modes are repeatedly rediscovered across users, preventing the system from improving with experience.”¹

Ich lebe seit Monaten mit diesem Fehlermuster. Sie auch, wenn Sie Skills für irgendeine Agent-Umgebung bauen.

TL;DR

Agent-Skills werden ausgeliefert und verbessern sich danach nicht mehr. Nutzer entdecken dieselben Fehlermuster unabhängig voneinander und speisen diese Entdeckungen nie wieder in den Skill selbst zurück. Ma et al. fassen dies als Problem kollektiver Intelligenz auf: Interaktionen über Nutzer und Zeit hinweg sind Signale dafür, wann ein Skill funktioniert oder versagt, aber es existiert kein Mechanismus auf Ökosystemebene, um sie zu Skill-Updates zu aggregieren. Ihr SkillClaw-Framework schlägt vor, aggregierte Trajektorien als Evolutionssignal zu behandeln und einen autonomen Evolver laufen zu lassen, der wiederkehrende Verhaltensmuster identifiziert und in Verfeinerungen oder Fähigkeitserweiterungen übersetzt.¹ Das Abstract nennt „OpenClaw” als Beispiel für einen LLM-Agenten, der wiederverwendbare Skills nutzt – ich konnte OpenClaw allein auf Basis des Abstracts nicht als konkretes ausgeliefertes Produkt identifizieren, und ich werde in diesem Beitrag nicht darüber spekulieren. Worauf ich hinauswill, ist, dass das strukturelle Problem, das das Paper beschreibt, auf jeden zutrifft, der Skills für Claude Code, Codex, Cursor oder einen eigenen Harness baut. Die Kernaussage: Wenn Ihre Skill-Bibliothek nicht kontinuierlich Trajektorien aus realer Nutzung aufnimmt, ist sie tot ab dem Tag der Auslieferung.

Wichtigste Erkenntnisse

• Skill-Autoren: Die Arbeit ist nicht abgeschlossen, wenn der Skill ausgeliefert wird. Die Arbeit ist abgeschlossen, wenn Sie eine Schleife haben, die beobachtet, wie der Skill genutzt wird, wiederkehrende Fehlermuster erkennt und sie in die Skill-Definition zurückführt. Die Auslieferung ist der Beginn des Skill-Lebens, nicht sein Ende.
• Harness-Entwickler: Protokollieren Sie jede Skill-Invokation samt Trajektorie – Eingaben, Tool-Aufrufe, Ausgaben, Fehlerzustand. Dieses Log ist das Evolutionssignal. Wenn Sie es nicht protokollieren, verbessern Sie Ihre Skills nicht; Sie pflegen sie lediglich.
• Jiro-orientierte Praktiker: Das SkillClaw-Paper ist akademische Sprache für das Shokunin-Muster, angewendet auf Skills. Der Skill ist das Handwerk. Die Trajektorien sind die Übung. Die Evolution ist das Streben nach Meisterschaft. Statisch = tot.

Was das Paper tatsächlich sagt

Ich werde die Aussagen des Abstracts sorgfältig durchgehen und dann klar markieren, wo ich die Rahmung erweitere.

Die Problemstellung (aus dem Abstract). LLM-Agenten sind auf wiederverwendbare Skills angewiesen, um komplexe Aufgaben auszuführen. Diese Skills bleiben nach der Auslieferung weitgehend statisch. Ähnliche Workflows, Muster der Tool-Nutzung und Fehlermuster werden wiederholt über Nutzer hinweg neu entdeckt. Das System verbessert sich nicht mit Erfahrung.¹

Das ist eine Aussage über ein bestimmtes Fehlermuster, nicht die Behauptung, dass alle Skills verfallen. Ein Skill, der nie aufgerufen wird, verfällt nicht. Ein Skill, der von einem einzigen Nutzer aufgerufen wird, der nie Probleme meldet, verfällt nicht sichtbar. Der Verfall zeigt sich, wenn Sie mehrere Nutzer haben, von denen jeder seine eigene Version desselben Fehlers erlebt, und das System keine Möglichkeit hat, diese Erfahrungen zu einem einzigen Update zu aggregieren. (Dieser letzte Satz ist meine Rahmung, nicht die des Papers.)

Die bestehende Lücke (aus dem Abstract). Das Abstract stellt fest, dass nutzerübergreifende Interaktionen zwar „complementary signals about when a skill works or fails” liefern, „existing systems lack a mechanism to convert such heterogeneous experiences into reliable skill updates.”¹ Das ist die tragende Aussage. Es ist nicht so, dass niemand über Skill-Verbesserung nachgedacht hätte. Es ist so, dass kein Mechanismus auf Ökosystemebene Trajektorien aggregiert, wiederkehrende Muster identifiziert und sie in Updates übersetzt.

Die SkillClaw-Pipeline (aus dem Abstract). Das Abstract beschreibt eine kontinuierliche Pipeline: SkillClaw „aggregates trajectories generated during use and processes them with an autonomous evolver, which identifies recurring behavioral patterns and translates them into updates to the skill set by refining existing skills or extending them with new capabilities.”¹ Die aktualisierten Skills werden in einem gemeinsamen Repository gepflegt und über Nutzer hinweg synchronisiert, sodass in einem Kontext entdeckte Verbesserungen systemweit propagieren, ohne dass Nutzeraufwand erforderlich ist.¹

Die Evaluation (aus dem Abstract). Das Paper evaluiert SkillClaw auf einem Benchmark namens WildClawBench unter Verwendung von Qwen3-Max als Basismodell. Die Formulierung des Abstracts ist in der veröffentlichten Fassung grammatikalisch gebrochen: „experiments on WildClawBench show that limited interaction and feedback, it significantly improves the performance of Qwen3-Max in real-world agent scenarios.”¹ Ich lese dies so: Mit begrenzter Interaktion und Feedback liefert SkillClaw dennoch signifikante Leistungsverbesserungen gegenüber der Baseline. Das Abstract nennt keine konkreten Zahlen – das vollständige Paper vermutlich schon.

Das ist das Paper, wie es vom Abstract beschrieben wird. Die Autoren schlagen vor, dass Multi-User-Agent-Ökosysteme mit gemeinsamen Skills von einer automatisierten Trajektorien-Aggregation profitieren, die automatisierte Skill-Updates speist, und sie berichten, dass ihre Implementierung die Leistung von Qwen3-Max unter Bedingungen mit begrenztem Feedback signifikant verbessert.

Was das Paper nicht sagt (und was ich hinzufüge)

Das Abstract nennt „OpenClaw” als ein Beispiel („LLM agents such as OpenClaw”) für einen Agenten, der wiederverwendbare Skills nutzt. Ich weiß allein aus dem Abstract nicht, was OpenClaw ist – ich konnte es nicht schnell als konkretes ausgeliefertes Produkt identifizieren. Das Framework des Papers (SkillClaw) wird als Lösung für Multi-User-Agent-Ökosysteme im Allgemeinen präsentiert, nicht spezifisch für OpenClaw, sodass die Frage „Was ist OpenClaw” für das Argument weitgehend nebensächlich ist. Ich weise darauf hin, damit niemand diesen Beitrag liest und mit dem Eindruck weggeht, das Paper handle von Claude Code. Das tut es nicht. Es nennt OpenClaw als Beispiel und schlägt SkillClaw als allgemeinen Mechanismus vor.

Was ich behaupte – getrennt vom Paper – ist, dass das strukturelle Problem, das das Paper beschreibt, auf ein reales Problem zutrifft, mit dem ich im Claude Code-Skill-Ökosystem lebe. Diese Behauptung ist meine, nicht die des Papers. Hier ist, warum ich denke, dass sie zutrifft.

Skills im Claude Code-Ökosystem werden als statische Artefakte ausgeliefert. Ein Skill ist eine SKILL.md-Datei (oder ein Bündel unterstützender Dateien), die beschreibt, wie eine Aufgabe ausgeführt werden soll. Sie schreiben ihn einmal. Sie committen ihn. Sie referenzieren ihn per Slash-Befehl oder via @skill-name-Typeahead. Sobald er ausgeliefert ist, ist er ein statisches Artefakt. Es existiert kein automatischer Mechanismus, der beobachtet, wie der Skill in der Praxis genutzt wird, und die Skill-Definition basierend auf dem aktualisiert, was funktioniert und was fehlschlägt.

Unterschiedliche Nutzer stoßen unabhängig auf dieselben Fehlermuster. Jeder Skill, den ich ausgeliefert habe, hat mindestens ein wiederkehrendes Fehlermuster, das nur unter bestimmten Bedingungen auftritt. Jemand ruft den Skill mit einer Eingabe auf, die ich nicht antizipiert habe, trifft auf den Grenzfall, umgeht ihn manuell und arbeitet weiter. Eine andere Person, irgendwo anders, trifft auf denselben Grenzfall und erstellt ihren eigenen Workaround. Der Skill selbst bleibt unverändert.

Das aggregierte Signal ist real, aber ungenutzt. Könnte ich jede Trajektorie jeder Invokation jedes Skills sehen, den ich ausgeliefert habe, könnte ich die wiederkehrenden Fehlermuster an einem Nachmittag identifizieren. Dieses Signal existiert – es steckt in der Sitzungshistorie jedes einzelnen Nutzers. Es wird nur nirgendwo aggregiert, also handelt niemand danach.

Die Lösung ist entweder manuell oder fehlt. Derzeit besteht der einzige Mechanismus zur Skill-Verbesserung darin, dass ich ein Problem in meiner eigenen Nutzung bemerke, jemand ein Issue einreicht oder jemand einen PR öffnet. Das sind allesamt Pfade, die Nutzeraufwand erfordern. Die Kernerkenntnis des SkillClaw-Papers – dass die Trajektoriendaten bereits existieren und automatisch in Skill-Updates umgewandelt werden sollten – ist genau der Mechanismus, der uns fehlt.

Das ist meine Behauptung darüber, wie die Rahmung des Papers auf Claude Code zutrifft. Es ist nicht, was das Paper sagt. Es ist, wie ich das Paper gegen meine eigene Arbeit lese.

Das Shokunin-Muster, angewendet auf Skills

Es gibt eine Rahmung, zu der ich immer wieder zurückkehre, wenn ich über Handwerk nachdenke. Jiro Ono, der Sushi-Meister, ist das kanonische Beispiel. Sechzig Jahre derselben Arbeit. Jeden Tag beobachten, was am Tresen passiert, die Technik anpassen, die Reistemperatur verfeinern, den Messerwinkel, das Timing des Shari. Die Arbeit selbst ist das Trainingssignal. Der Praktiker ist der Aggregator.

Ich habe vor einiger Zeit über die Shokunin-/Quality-Loop-Rahmung geschrieben. Die Kernidee: Das Handwerk ist die Feedbackschleife. Sie machen die Arbeit, Sie beobachten die Arbeit, Sie bemerken, was zerbrochen ist, Sie passen an, Sie machen die Arbeit erneut. Immer wieder. Die Meisterschaft liegt im Delta zwischen dem, was Sie beabsichtigt haben, und dem, was tatsächlich geschehen ist, und in Ihrer Bereitschaft, dieses Delta in den nächsten Versuch mitzunehmen.

Ein statischer Skill durchbricht diese Schleife. Sie liefern den Skill aus. Sie hören auf zu beobachten. Das Delta zwischen dem, was der Skill beabsichtigte, und dem, was tatsächlich geschieht, häuft sich in hundert verschiedenen Sitzungen an, die Sie nie sehen. Der Skill wird nicht besser, weil der Handwerker nicht am Tresen steht.

Das SkillClaw-Paper schlägt einen automatisierten Aggregator vor – keinen Ersatz für den Menschen, sondern einen Mechanismus, der alle Trajektorien beobachtet, bemerkt, was über Sitzungen hinweg zerbrochen ist, und Updates zurück in die Skill-Definition vorschlägt. Das ist keine verrückte Ambition. Es ist tatsächlich die Mindestanforderung, wenn ein Skill seine eigene Auslieferung überleben soll.

Wie das in der Praxis aussieht

Wenn ich das SkillClaw-Muster gegen Claude Code-Skills bauen wollte, die ich heute pflege, bräuchte ich Folgendes:

1. Ein Trajektorien-Log für jede Skill-Invokation. Jedes Mal, wenn ein Skill läuft, die Eingaben, die Tool-Aufrufe, die er tätigt, die Ausgaben, die Fehlerzustände und die endgültige Disposition (hat der Nutzer das Ergebnis akzeptiert? zurückgenommen? umgeschrieben?). Dies existiert in Claude Code bereits auf Sitzungsebene – die Frage ist, ob es über Sitzungen hinweg aggregiert und für den Skill-Eigentümer extrahiert wird.

2. Ein Mustererkenner. Etwas, das das Trajektorien-Log liest und wiederkehrende Muster identifiziert: dieselbe Eingabeklasse, die zum selben Fehler führt, derselbe Tool-Aufruf, der auf dieselbe Weise fehlschlägt, derselbe Grenzfall, der unter unterschiedlichen Nutzerkontexten auftritt. Das ist keine AGI – es ist Clustering auf strukturierten Trajektoriendaten.

3. Ein Vorschlagsgenerator. Bei einem erkannten Muster wird ein Kandidaten-Update für den Skill entworfen: ein neuer Handhabungszweig, ein zusätzliches Beispiel, eine weitere Einschränkung im Körper der SKILL.md. Das Update ist ein Vorschlag, keine ausgelieferte Änderung.

4. Ein Gate. Jedes vorgeschlagene Update durchläuft eine menschliche Überprüfung, eine faktische Verifikation (dasselbe harte Gate, das ich auf alles andere anwende) und eine Critique-Schleife, bevor es ausgeliefert wird. Die Automatisierung übernimmt die Aggregation, nicht die Auslieferung.

5. Verteilung. Wird ein vorgeschlagenes Update akzeptiert, propagiert es zu jedem Nutzer dieses Skills. In einem zentralisierten Ökosystem ist das trivial (kanonischen Skill aktualisieren, alle ziehen nach). In einem verteilten Ökosystem ist es schwieriger.

Das meiste davon ist in Claude Code bereits vorhanden – Sitzungsprotokollierung existiert, Skill-Definitionen sind versioniert, die Critique-Schleife ist operativ – das fehlende Stück ist die Aggregations- und Mustererkennungsebene, die Sitzungs-Trajektorien mit Skill-Updates verbindet.

Die unangenehme Implikation

Jeder Skill, den ich in den letzten sechs Monaten ausgeliefert habe, ist tot in genau dem Sinne, wie es das SkillClaw-Paper beschreibt. Ich schreibe den Skill. Ich nutze ihn selbst. Ich bemerke Probleme. Ich behebe sie in den Skills, die ich nutze. Die Skills werden für mich besser. Sie werden für niemanden sonst besser, es sei denn, diese Person bemerkt unabhängig dasselbe Problem und meldet etwas.

Die Arbeit, die ich gestern Abend an der Settings Reference geleistet habe, ist genau dieses Muster. Der Claude Code-Guide ist ein gemeinsames Artefakt. Nutzer fragen ihn nach bestimmten Config-Schlüsseln ab. Ich kann die GSC-Daten sehen, die mir sagen, welche Config-Schlüssel gesucht werden. Das sind aggregierte Trajektoriendaten – sie sagen mir buchstäblich, welche Skills im Guide aufgerufen werden und wo die Ergebnisse landen. Und bis ich mir diese Daten angesehen habe, war der Guide statisch. Er war wochenlang statisch gewesen. Nicht, weil niemand die Trajektorien beobachtete, sondern weil ich die einzige Person war, die sie beobachten konnte, und ich anderes zu tun hatte.

Das SkillClaw-Paper ist die akademische Formalisierung des Problems. Der praktische Mechanismus ist einfacher: Wenn Sie keine automatische Pipeline von Trajektoriendaten zu Skill-Updates haben, altern Ihre Skills an Ort und Stelle. Sie funktionieren vielleicht noch für einige Nutzer unter bestimmten Bedingungen. Besser werden sie nicht.

Die einzige Frage ist, ob Sie akzeptieren, dass Ihre Skills in dem Moment tot sind, in dem sie ausgeliefert werden, oder ob Sie den Beobachter bauen, der sie am Leben hält.

Der Minimum Viable Aggregator

Bevor ich mit diesem Beitrag begann, hatte ich null Trajektorien-Aggregation für meine Skills. Keine. Ich hatte eine Sitzungshistorie, die ich manuell lesen konnte, aber nichts, was Muster über Sitzungen hinweg sichtbar machte. Das ist genau die Pathologie statischer Skills, die das Paper beschreibt, und ich habe sie gelebt.

Hier ist das Kleinste, was ich sofort, heute, dagegen ausliefern kann: eine einzige Textdatei, die jede Skill-Invokation über meine eigenen Sitzungen hinweg append-only protokolliert, mit Zeitstempel + Skill-Name + Eingabeform + endgültiger Disposition (akzeptiert / überarbeitet / zurückgenommen). Kein Mustererkenner. Kein autonomer Evolver. Nur das Log.

Diese Datei ist der Minimum Viable Aggregator. Sie ist nicht SkillClaw. Sie ist die Eingabeschicht, die SkillClaw bräuchte, wenn es existierte, und sie ist die Eingabeschicht, die ich brauche, bevor ich überhaupt sehen kann, ob meine Skills wiederkehrende Fehlermuster haben. Ohne sie rate ich. Mit ihr kann ich das Log zumindest manuell durchgehen, wenn ich einen Skill überprüfe, und fragen: Ist dieses Ding diesen Monat dreimal auf dieselbe Weise zerbrochen?

Das ist die Verpflichtung. Eine Datei. Append-only. Pro Invokation protokolliert. Überprüft, wenn ich den Skill überprüfe.

Wenn das funktioniert, ist die nächste Ebene der Mustererkenner. Wenn der Mustererkenner funktioniert, ist die nächste Ebene der Vorschlagsgenerator. Die Ambition des Papers ist ein vollständig autonomer Evolver, der über ein Multi-User-Ökosystem läuft. Meine Ambition ist es, nicht im Dunkeln zu laufen.

FAQ

Ist „OpenClaw” im Paper dasselbe wie Claude Code?

Nein, und ich kann Ihnen auch nicht sagen, was OpenClaw ist. Das Abstract erwähnt „LLM agents such as OpenClaw” als ein Beispiel für einen Agenten, der wiederverwendbare Skills nutzt, ohne es zu definieren. Ich konnte es allein aus dem Abstract nicht schnell als konkretes ausgeliefertes Produkt identifizieren. Entscheidend ist, dass das SkillClaw-Framework des Papers als allgemeine Lösung für Multi-User-Agent-Ökosysteme präsentiert wird, nicht als Lösung spezifisch für OpenClaw oder Claude Code. Was auch immer OpenClaw ist, das Paper ist kein Claude Code-Paper, und meine Aussagen über Claude Code in diesem Beitrag sind meine eigenen, nicht die des Papers.¹

Was ist der eigentlich neuartige Beitrag des Papers?

Laut Abstract: ein Framework für kollektive Skill-Evolution in Multi-User-Agent-Ökosystemen, das (1) Trajektorien über Nutzer und Zeit hinweg aggregiert, (2) einen autonomen Evolver laufen lässt, um wiederkehrende Muster zu erkennen, und (3) Muster in Updates für Skills in einem gemeinsamen Repository übersetzt, die über Nutzer hinweg synchronisieren.¹ Die Neuigkeit ist nicht „Skills können verbessert werden” – das ist offensichtlich. Die Neuigkeit besteht in dem Vorschlag, dass die Verbesserungsschleife autonom und trajektoriengetrieben sein sollte, nicht menschengetrieben.

Nennt das Paper konkrete Verbesserungszahlen?

Das Abstract beschreibt die Verbesserung als „significant” auf einem Benchmark namens WildClawBench unter Verwendung von Qwen3-Max, unter Bedingungen mit begrenztem Feedback, nennt aber keine konkreten Zahlen.¹ Für Zahlen ist das vollständige Paper die Quelle.

Warum unterscheidet sich das von einem Git-Pull-Request gegen eine Skill-Definition?

Ein PR ist ein von Menschen initiierter Mechanismus. Jemand muss das Problem bemerken, den Fix schreiben, den PR einreichen, ihn überprüfen, ihn mergen. Jeder Schritt erfordert menschlichen Aufwand. Das SkillClaw-Framework, das das Paper vorschlägt, ist autonome Aggregation – das System bemerkt das Muster über viele Nutzer hinweg, schlägt den Fix selbst vor und synchronisiert das Update, ohne dass ein einzelner Nutzer etwas einreichen muss.¹ Ob diese autonome Variante für ein bestimmtes Ökosystem wünschenswert oder sicher ist, ist eine separate Frage. Der Beitrag des Papers besteht darin zu zeigen, dass es technisch stimmig ist.

Gilt das für meine eigenen Claude Code-Skills?

Das Paper macht keine Aussagen über ein spezifisches Claude Code-Skill-Ökosystem. Meine Behauptung – getrennt vom Paper – ist, dass das strukturelle Problem (Skills als statische Artefakte ausgeliefert, Fehlermuster von jedem Nutzer unabhängig neu entdeckt, kein Aggregationsmechanismus) auf Claude Code-Skills zutrifft, und dass jeder, der Skills für Claude Code oder einen ähnlichen Harness baut, darüber nachdenken sollte, wie man eine trajektoriengetriebene Verbesserungsschleife aufbaut. Das ist meine Meinung, kein Befund aus dem Paper.

Was ist die Shokunin-Verbindung?

Die Shokunin-/Quality-Loop-Rahmung argumentiert, dass Meisterschaft aus dem Delta zwischen dem, was Sie beabsichtigt haben, und dem, was tatsächlich geschehen ist, entsteht, getragen in den nächsten Versuch. Statische Skills durchbrechen diese Schleife, weil sich die Deltas in Sitzungen ansammeln, die der Handwerker nie sieht. SkillClaw ist die akademische Version des Schließens dieser Schleife – die Sammlung der Deltas wird automatisiert und in den Skill zurückgeführt. Die Disziplin ist dieselbe; der Mechanismus ist ein anderer.

Quellenangaben