Statische Skills sind tote Skills

Gestern Abend habe ich einen Bereich „Settings Reference” für den Claude Code Guide ausgeliefert. Fünfzehn Einträge. Jede Zitation per Grep gegen eine Zeilennummer geprüft. Ich habe ihn aus Überzeugung ausgeliefert, nachdem die Kritik-Schleife sauber zurückkam. Während ich die .md-Datei 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, das zugrunde liegende Produkt sich ändert, die Benutzeranfragen sich verschieben, und der Abschnitt, den ich gerade ausgeliefert hatte, in dem Moment zu driften beginnen würde, in dem ich mich abwende.

Ein Skill (egal ob ein Markdown-Referenzabschnitt oder eine Agent-Skill-Definition in .claude/skills/) lebt nur so lange, wie jemand seine Trajektorie beobachtet. In dem Moment, in dem Sie aufhören zu beobachten, wird er statisch. Statische Skills verfallen auf der Stelle. Der folgende Beitrag ist Teil der Serie AI engineering, die dokumentiert, wie sich Agent-Infrastruktur in der Produktion weiterentwickelt.

Statische KI-Agent-Skills scheitern, weil sie in dem Moment aufhören zu lernen, in dem sie ausgeliefert werden. Ohne eine Feedback-Schleife, die echte Aufruf-Trajektorien aufnimmt (die Eingaben, Tool-Aufrufe, Ausgaben und Fehlerzustände aus tatsächlicher Nutzung), können sich Skills nicht an sich ändernde Produkte, verschobene Benutzeranfragen oder wiederkehrende Fehlermodi anpassen. Mehrere Benutzer entdecken unabhängig voneinander dieselben Workarounds wieder, während die Skill-Definition eingefroren bleibt. Die Lösung: kontinuierliche Trajektorien-Aggregation, die Nutzungsmuster in automatisierte Skill-Updates umwandelt.

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 in diesem Fehlermodus seit Monaten. Sie auch, wenn Sie Skills für irgendein Agent-Framework bauen.

TL;DR

Agent-Skills werden ausgeliefert und hören dann auf, sich zu verbessern. Benutzer entdecken dieselben Fehlermodi unabhängig voneinander und speisen diese Entdeckungen nie in den Skill selbst zurück. Ma et al. rahmen dies als Problem kollektiver Intelligenz: nutzerübergreifende und zeitliche Interaktionen sind Signale darüber, wann ein Skill funktioniert oder versagt, aber kein Mechanismus auf Ökosystemebene existiert, 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 sie 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 anhand des Abstracts nicht als spezifisches ausgeliefertes Produkt identifizieren, und ich werde in diesem Beitrag nicht darüber spekulieren. Was ich sehr wohl behaupten werde: Das strukturelle Problem, das das Paper beschreibt, lässt sich auf jeden übertragen, der Skills für Claude Code, Codex, Cursor oder sein eigenes Agent-Framework baut. Die Kernaussage: Wenn Ihre Skill-Bibliothek nicht kontinuierlich Trajektorien aus echter Nutzung aufnimmt, ist sie ab dem Tag ihrer Auslieferung tot.

Kernpunkte

• Skill-Autoren: Die Arbeit ist nicht getan, wenn der Skill ausgeliefert wird. Die Arbeit ist getan, wenn Sie eine Schleife haben, die beobachtet, wie der Skill verwendet wird, wiederkehrende Fehlermodi einfängt und sie in die Skill-Definition zurückspeist. Die Auslieferung ist der Beginn des Lebens des Skills, nicht das Ende.
• Framework-Entwickler: Protokollieren Sie jeden Skill-Aufruf mit seiner Trajektorie: die Eingaben, die Tool-Aufrufe, die Ausgaben, den Fehlerzustand. Dieses Protokoll ist das Evolutionssignal. Wenn Sie es nicht protokollieren, verbessern Sie Ihre Skills nicht; Sie verwalten sie lediglich.
• Jiro-orientierte Praktiker: Das SkillClaw-Paper ist akademische Sprache für das Shokunin-Muster, angewandt 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 stützen sich auf wiederverwendbare Skills, um komplexe Aufgaben auszuführen. Diese Skills bleiben nach der Bereitstellung weitgehend statisch. Ähnliche Workflows, Tool-Nutzungsmuster und Fehlermodi werden von verschiedenen Benutzern wiederholt neu entdeckt. Das System verbessert sich nicht mit der Erfahrung.¹

Die Autoren zielen auf einen spezifischen Fehlermodus ab, nicht auf eine universelle Behauptung, dass alle Skills verfallen. Ein Skill, der nie aufgerufen wird, verfällt nicht. Ein Skill, den ein Benutzer ohne Probleme aufruft, verfällt nicht sichtbar. Der Verfall zeigt sich, wenn mehrere Benutzer jeweils ihre eigene Version desselben Fehlers erleben und das System keinen Weg hat, diese Begegnungen 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 „provide complementary signals about when a skill works or fails, existing systems lack a mechanism to convert such heterogeneous experiences into reliable skill updates”.¹ Die tragende Aussage sitzt hier. Die Lücke besteht nicht darin, dass niemand über Skill-Verbesserung nachgedacht hätte. Die Lücke besteht darin, 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”.¹ Das System verwaltet aktualisierte Skills in einem gemeinsamen Repository und synchronisiert sie über Benutzer hinweg, sodass Verbesserungen, die in einem Kontext entdeckt werden, sich systemweit ausbreiten, ohne dass Benutzeraufwand erforderlich ist.¹

Die Evaluierung (aus dem Abstract). Das Paper evaluiert SkillClaw auf einem Benchmark namens WildClawBench unter Verwendung von Qwen3-Max als zugrundeliegendem Modell. Die Formulierung des Abstracts ist in der veröffentlichten Version 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 das als: mit begrenzter Interaktion und begrenztem Feedback produziert SkillClaw dennoch signifikante Leistungsverbesserungen gegenüber der Baseline. Das Abstract veröffentlicht keine konkreten Zahlen; das vollständige Paper vermutlich schon.

Das ist das Paper, wie das Abstract es beschreibt. Die Autoren schlagen vor, dass Multi-User-Agent-Ökosysteme mit gemeinsamen Skills von automatisierter 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 spezifisches ausgeliefertes Produkt identifizieren. Das Framework des Papers (SkillClaw) zielt allgemein auf Multi-User-Agent-Ökosysteme ab, nicht speziell auf 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 denkt, das Paper handele von Claude Code. Tut es nicht. Es nennt OpenClaw als Beispiel und schlägt SkillClaw als allgemeinen Mechanismus vor.

Was ich, getrennt vom Paper, behaupte, ist, dass sich das strukturelle Problem, das das Paper beschreibt, auf ein reales Problem abbilden lässt, in dem ich im Claude Code-Skill-Ökosystem gelebt habe. Diese Behauptung gehört mir, nicht dem Paper. Hier ist, warum ich denke, dass sie sich abbildet.

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 mit einem Slash-Befehl oder über @skill-name-Typeahead; die Mechanik des Building Custom Skills ist einfach. Sobald er ausgeliefert ist, ist er ein statisches Artefakt. Kein automatischer Mechanismus beobachtet, wie der Skill in der Praxis verwendet wird, oder aktualisiert die Skill-Definition basierend darauf, was funktioniert und was fehlschlägt.

Verschiedene Benutzer treffen unabhängig voneinander auf dieselben Fehlermodi. Jeder Skill, den ich ausgeliefert habe, hat mindestens einen wiederkehrenden Fehlermodus, der nur unter bestimmten Bedingungen auftritt. Jemand ruft den Skill mit einer Eingabe auf, die ich nicht antizipiert habe, trifft auf den Randfall, umgeht ihn manuell und geht weiter. Eine andere Person, irgendwo anders, trifft auf denselben Randfall und wendet ihren eigenen Workaround an. Der Skill selbst ändert sich nie.

Das aggregierte Signal ist real, aber ungenutzt. Wenn ich jede Trajektorie aus jedem Aufruf jedes Skills sehen könnte, den ich ausgeliefert habe, könnte ich die wiederkehrenden Fehlermodi an einem Nachmittag identifizieren. Dieses Signal existiert im Sitzungsverlauf jedes einzelnen Benutzers. Es wird nur nirgendwo aggregiert, sodass niemand darauf reagiert.

Die Lösung ist entweder manuell oder fehlt. Im Moment ist der einzige Mechanismus zur Skill-Verbesserung, dass ich ein Problem in meiner eigenen Nutzung bemerke oder jemand ein Issue einreicht oder jemand einen PR öffnet. All diese Pfade erfordern Benutzeraufwand. Die Kernerkenntnis des SkillClaw-Papers, dass die Trajektoriendaten bereits existieren und Skill-Updates automatisch speisen sollten, ist genau der Mechanismus, der uns fehlt.

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

Das Shokunin-Muster, angewandt auf Skills

Eine Rahmung taucht immer wieder auf, wenn ich über Handwerk nachdenke. Jiro Ono, der Sushi-Meister, ist das kanonische Beispiel. Sechzig Jahre derselben Arbeit. Jeden Tag beobachtet er, was am Tresen geschieht, passt die Technik an, verfeinert die Reistemperatur, 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 Feedback-Schleife. Sie tun die Arbeit, Sie beobachten die Arbeit, Sie bemerken, was gebrochen ist, Sie passen an, Sie tun die Arbeit wieder. Immer wieder. Die Meisterschaft lebt in der Differenz zwischen dem, was Sie beabsichtigt haben, und dem, was tatsächlich passiert ist, und in Ihrer Bereitschaft, diese Differenz in den nächsten Versuch zu tragen.

Ein statischer Skill bricht diese Schleife. Sie liefern den Skill aus. Sie hören auf zu beobachten. Die Differenz zwischen dem, was der Skill beabsichtigte, und dem, was tatsächlich passiert, sammelt sich in hundert verschiedenen Sitzungen an, die Sie nie sehen. Der Skill wird nicht besser, weil der Handwerker nicht am Tresen ist.

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 gebrochen ist, und Updates zurück in die Skill-Definition vorschlägt. Der Anspruch ist nicht verrückt. Er ist tatsächlich die Mindestmesslatte, wenn Sie wollen, dass ein Skill seine eigene Bereitstellung überlebt.

Wie das in der Praxis aussieht

Wenn ich das SkillClaw-Muster gegen Claude Code-Skills aufbauen wollte, die ich heute pflege, wäre das, was ich brauchen würde, Folgendes:

1. Ein Trajektorien-Log für jeden Skill-Aufruf. Jedes Mal, wenn ein Skill läuft, die Eingaben, die Tool-Aufrufe, die er macht, die Ausgaben, die Fehlerzustände und die endgültige Disposition (hat der Benutzer das Ergebnis akzeptiert? es zurückgesetzt? es neu geschrieben?). Sitzungsbezogene Protokollierung existiert bereits in Claude Code; die Frage ist, ob sie über Sitzungen hinweg aggregiert und für den Skill-Besitzer extrahiert wird.

2. Ein Mustererkennungssystem. 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 Randfall, der unter verschiedenen Benutzerkontexten auftritt. Die Anforderung ist Clustering auf strukturierten Trajektoriendaten, nicht AGI.

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

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

5. Verteilung. Wenn ein vorgeschlagenes Update akzeptiert wird, verbreitet es sich zu jedem Benutzer dieses Skills. In einem zentralisierten Ökosystem ist das trivial (aktualisieren Sie den kanonischen Skill, alle ziehen ihn). In einem verteilten Ökosystem ist das schwieriger.

Das meiste existiert bereits in Claude Code: Sitzungsprotokollierung, versionierte Skill-Definitionen, eine operative Kritik-Schleife. Das fehlende Stück ist die Aggregations- und Mustererkennungsschicht, die Sitzungstrajektorien mit Skill-Updates verbindet. Die organisatorische Taxonomie von Befehlen, Skills, Subagenten und Regeln bietet bereits die strukturelle Grundlage; was fehlt, ist der Feedback-Kanal, der jede Kategorie nach der Bereitstellung am Leben erhält.

Die unbequeme Konsequenz

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

Die Arbeit, die ich gestern Abend an der Settings Reference gemacht habe, ist genau dieses Muster. Der Claude Code Guide ist ein gemeinsames Artefakt. Benutzer fragen ihn nach spezifischen Konfigurationsschlüsseln ab. Ich kann die GSC-Daten sehen, die mir sagen, nach welchen Konfigurationsschlüsseln gesucht wird. Das sind aggregierte Trajektoriendaten, die mir buchstäblich sagen, welche Skills im Guide aufgerufen werden und wo die Ergebnisse landen. Und bis ich diese Daten angeschaut habe, war der Guide statisch. Er war wochenlang statisch. Nicht, weil niemand die Trajektorien beobachtet hätte, sondern weil ich die einzige Person war, die sie beobachten konnte, und ich andere Dinge 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 auf der Stelle. Sie funktionieren vielleicht noch für einige Benutzer unter einigen Bedingungen. Sie werden nicht besser.

Die einzige Frage ist, ob Sie akzeptieren, dass Ihre Skills in dem Moment sterben, in dem sie ausgeliefert werden, oder ob Sie den Beobachter bauen, der sie am Leben hält. Das Prinzip des Compound Context gilt hier: Jede Trajektorienbeobachtung verstärkt sich mit der nächsten, und der Wert des Skills wächst nichtlinear mit dem Feedback, das er aufnimmt. Umgekehrt bedeutet die Betrachtung von Kontext als Architektur die Erkenntnis, dass die Struktur eines Skills seine Fähigkeit bestimmt, überhaupt neue Informationen aufzunehmen.

Der minimal lebensfähige Aggregator

Bevor ich diesen Beitrag begonnen habe, hatte ich null Trajektorien-Aggregation für meine Skills. Keine. Ich hatte Sitzungsverlauf, den 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 konkrete Ding, das ich genau jetzt, heute ausliefern kann: eine einzige Textdatei, die jeden Skill-Aufruf über meine eigenen Sitzungen hinweg protokolliert, append-only, mit Zeitstempel + Skill-Name + Eingabeform + endgültiger Disposition (akzeptiert / überarbeitet / zurückgesetzt). Kein Mustererkennungssystem. Kein autonomer Evolver. Nur das Protokoll.

Diese Datei ist der minimal lebensfähige Aggregator. Sie ist nicht SkillClaw. Sie ist die Eingabeschicht, die SkillClaw brauchen würde, wenn es existierte, und die Eingabeschicht, die ich brauche, bevor ich überhaupt sehen kann, ob meine Skills wiederkehrende Fehlermodi haben. Ohne sie rate ich. Mit ihr kann ich zumindest das Protokoll per Hand durchgehen, wenn ich einen Skill überprüfe, und fragen: Ist dieselbe Panne diesen Monat dreimal aufgetreten?

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

Wenn das funktioniert, ist die nächste Schicht das Mustererkennungssystem. Wenn das Mustererkennungssystem funktioniert, ist die nächste Schicht der Vorschlagsgenerator. Der Anspruch des Papers ist ein vollständiger autonomer Evolver, der über ein Multi-User-Ökosystem läuft. Mein Anspruch ist, 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 anhand des Abstracts nicht schnell als spezifisches ausgeliefertes Produkt identifizieren. Das Wichtige: Das SkillClaw-Framework des Papers zielt allgemein auf Multi-User-Agent-Ökosysteme ab, nicht speziell auf OpenClaw oder Claude Code. Was auch immer OpenClaw ist, das Paper ist kein Claude Code-Paper, und meine Behauptungen über Claude Code in diesem Beitrag sind meine eigenen, nicht die des Papers.¹

Was ist der eigentliche neuartige Beitrag des Papers?

Laut Abstract: ein Framework für kollektive Skill-Evolution in Multi-User-Agent-Ökosystemen, das (1) Trajektorien über Benutzer und Zeit hinweg aggregiert, (2) einen autonomen Evolver zur Erkennung wiederkehrender Muster laufen lässt und (3) Muster in Updates zu Skills in einem gemeinsamen Repository übersetzt, die sich über Benutzer hinweg synchronisieren.¹ Die Neuheit ist nicht „Skills können verbessert werden” (das ist offensichtlich). Die Neuheit ist der Vorschlag, dass die Verbesserungsschleife autonom und trajektoriengetrieben sein sollte, nicht menschlich getrieben.

Berichtet das Paper konkrete Verbesserungszahlen?

Das Abstract beschreibt die Verbesserung auf einem Benchmark namens WildClawBench mit Qwen3-Max unter Bedingungen mit begrenztem Feedback als „signifikant”, veröffentlicht jedoch keine konkreten Zahlen.¹ Für Zahlen ist das vollständige Paper die Quelle.

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

Ein PR ist ein menschlich 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 Benutzer hinweg, schlägt den Fix selbst vor und synchronisiert das Update, ohne dass ein einzelner Benutzer etwas einreichen muss.¹ Ob diese autonome Version für irgendein spezifisches Ökosystem wünschenswert oder sicher ist, ist eine separate Frage. Der Beitrag des Papers besteht darin, zu zeigen, dass sie technisch kohärent ist.

Gilt das für meine benutzerdefinierten 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, die als statische Artefakte ausgeliefert werden, Fehlermodi, die von jedem Benutzer unabhängig neu entdeckt werden, kein Aggregationsmechanismus) auf Claude Code-Skills zutrifft und dass jeder, der Skills für Claude Code oder ein ähnliches Agent-Framework baut, darüber nachdenken sollte, wie man eine trajektoriengetriebene Verbesserungsschleife aufbaut. Das ist meine Meinung, keine Erkenntnis aus dem Paper.

Was ist die Shokunin-Verbindung?

Die Shokunin- / Quality-Loop-Rahmung argumentiert, dass Meisterschaft aus der Differenz zwischen dem, was Sie beabsichtigt haben, und dem, was tatsächlich passiert ist, kommt, die in den nächsten Versuch getragen wird. Statische Skills brechen diese Schleife, weil sich die Differenzen in Sitzungen ansammeln, die der Handwerker nie sieht. SkillClaw ist die akademische Version, diese Schleife zu schließen: die Sammlung von Differenzen zu automatisieren und sie in den Skill zurückzuspeisen. Die Disziplin ist dieselbe; der Mechanismus ist unterschiedlich.

Referenzen