Selbstverbessernde Agenten durch Fähigkeiten: Wiederverwendung, Auswahl, Reparatur und Überprüfung.

Ein Programmieragent, der auf dasselbe Problem zweimal stößt, fehlt in der Regel ein dauerhafter Ort, an dem er das Gelernte speichern kann. Die Idee hinter einem Plugin namens Whetstone ist, dass die Arbeit, die ein Agent heute leistet, die Arbeit von morgen verbessern sollte. Ein Hilfsmittel, das der Agent selbst geschrieben und getestet hat, sollte beim nächsten Mal bereits vorhanden sein. Ein Arbeitsablauf, der einer Korrektur bedarf, sollte zu einer dauerhaften Änderung führen, die von jemandem überprüft werden kann. Und bevor ein Ergebnis übergeben wird, sollten bereits die notwendigen Überprüfungen durchgeführt worden sein.

Das sind gewöhnliche ingenieurtechnische Gewohnheiten, doch sie bleiben oft nur im Kopf einer Person und werden am Ende jeder Sitzung wiederholt. Whetstone fasst sie als vier Fähigkeiten zusammen, die auf anderen Fähigkeiten beruhen: Wiederverwendung bewährten Codes, Verbesserung der Auswahl der Fähigkeiten, Erfassung von Verfahrenserfahrungen sowie Überprüfung der Ausgabe, bevor sie an den Benutzer zurückgegeben wird.

Der Begriff „selbstverbessernde Agenten“ wird hier in einem bewusst bescheidenen Sinne verwendet. Der Agent hilft dabei, seine eigenen Anweisungen und Werkzeuge zu verbessern, ein Mensch prüft die Änderungen und entscheidet, was dauerhaft bleibt; das Modell selbst wird nicht neu trainiert, und nichts läuft im Hintergrund unbeaufsichtigt, um von selbst zu lernen.

Eine anfängliche Überprüfung von 383 Fähigkeitsdateien bot dem Plugin einen konkreten Testbereich. Noch wichtiger ist jedoch das Design: Wo wiederverwendbare Aufgaben untergebracht werden sollten, wie die richtige Intervention gewählt wird und welche Beweise vor der Beibehaltung einer Änderung gefordert werden. Diese Überlegungen gelten sowohl für das Plugin als auch für eine Version, die auf Ihren eigenen Arbeitsabläufen basiert.

Der Teil eines Agenten, den man tatsächlich verbessern kann

Eine Fähigkeit ist ein Ordner. Er enthält eine SKILL.md-Datei mit Anweisungen sowie optional Skripte und Referenzdokumente. Die offizielle Agent Skills-Spezifikation legt ein einheitliches Layout fest, bei dem der Datei ein kurzer Name und eine Beschreibung vorausgehen. Das Ingenieurteam von Anthropic beschreibt Fähigkeiten als Möglichkeit, allgemein einsetzbaren Agenten wiederverwendbare Expertise zu verleihen; der Vorteil dabei ist, dass Verfahren verbessert werden können, ohne den Laufzeitmechanismus neu aufbauen zu müssen.

Dabei sind zwei getrennte Aufgaben beteiligt: Der Agent muss die richtige Fähigkeit auswählen, und die ausgewählte Fähigkeit muss anschließend die Arbeit gut leiten. Die Behebung eines Problems behebt nicht automatisch das andere.

Whetstone weist jeder seiner vier Fähigkeiten eine einzige Aufgabe zu:

• dry-promotion bewahrt wiederverwendbaren Code auf.
• skill-audit überprüft die zur Auswahl der Fähigkeit verwendeten Informationen.

skill-repair schlägt prozedurale Änderungen vor.

verify-before-return überprüft die Ausgabe.

Was die Trennung funktionierbar macht, ist, dass jede Operation etwas anderes ändert. Ein Hilfsprogramm könnte trotz fehlgeschlagener Aktionen gespeichert werden. Eine vage Beschreibung benötigt möglicherweise Aufmerksamkeit, obwohl die zugrunde liegende Prozedur einwandfrei funktioniert. Jede Anfrage durch alle vier Operationen zu leiten, würde unzusammenhängende Aufgaben miteinander verknüpfen, während getrennte Eingangspunkte es ermöglichen, nur den Teil aufzurufen, den eine Aufgabe benötigt.

Jede Operation endet mit etwas, das man betrachten kann: einer Datei auf der Festplatte, einem Prüfbericht, einem vorgeschlagenen Diff oder Beweisen für die Überprüfung. Das erleichtert das Debuggen und gibt dem Prüfer etwas Konkretes zur Genehmigung. Die Hilfe des Agenten ist willkommen, doch eine überzeugende Erklärung allein macht eine Änderung niemals dauerhaft.

1. DRY: Die bereits erfolgreiche Arbeit beibehalten

DRY steht für „wiederhole dich nicht“ und bezieht sich auf einen Agenten, der Code verwendet, den er zuvor bereits erstellt hat. Wenn jede Anfrage zur Darstellung eine Neuerrichtung des Renderers erzwingt, muss dieser zunächst ein altes Ingenieurproblem lösen, bevor er sich mit dem neuen Inhalt beschäftigen kann.

Der Renderer ist die wiederverwendbare Mechanik, während der Inhalt sich ändert. In Anthropics Dokumentation wird ein ähnlicher Punkt mit einer PDF-Fähigkeit veranschaulicht, die einen im Voraus geschriebenen Extraktionsscript ausführt: Der Code übernimmt den stabilen mechanischen Teil, während das Modell die für die Aufgabe spezifischen Entscheidungen trifft.

Das ist die Aufgabe von dry-promotion. Es kopiert einen nützlichen Hilfsprogramm in den scripts/-Ordner der Fähigkeit und schreibt die Anweisungen um, sodass das Script ausgeführt wird. Das Alleinige Speichern einer Datei reicht nicht aus: Obwohl die Fähigkeit dem Agenten weiterhin mitteilt, ein Script schreiben zu sollen, weist nichts darauf hin, welche Datei gemeint ist.

Ein Zeichenzähler ist ein gutes Beispiel aus einem Schreibworkflow. Untertitel haben eine Längengrenze, und ein kleines Programm kann die Anzahl der Zeichen berechnen, während sich das Modell auf die Formulierung konzentriert. Die Anleitung könnte in etwa so lauten:

Vor der Rückgabe eines Untertitels soll der gespeicherte Zeichenzähler ausgeführt werden. Wenn das Ergebnis die Grenze überschreitet, muss die Formulierung verkürzt und erneut gezählt werden. Man darf niemals auf Schätzung vertrauen und den Zähler auch nicht neu erstellen.

Dadurch entsteht eine stabile Implementierung, die überprüft und getestet werden kann. Der gesamte Workflow wird dadurch jedoch nicht deterministisch, da der Untertitel selbst weiterhin variieren kann und ein Programm eine falsche Definition getreu wiederholen könnte. Der Zähler muss klären, ob er Unicode-Codepunkte oder sichtbare Zeichen zählt sowie wie er Leerzeichen und Zeilenumbrüche behandelt.

Erstellen Sie vor der Verwendung eines Hilfsprogramms eine Vorbereitung: Entfernen Sie Pfade, die mit einer bestimmten Sitzung verbunden sind, machen Sie die Eingabefelder explizit und testen Sie es an Fällen, die über den ursprünglichen Anlass hinausgehen. Führen Sie anschließend den Workflow erneut aus und überprüfen Sie, ob die gespeicherte Datei tatsächlich die erwartete ist. Ein Ablauf, bei dem heimlich ein weiterer Zähler erstellt wird, untergräbt den Sinn der Wiederverwendung – selbst wenn die Endzahlen übereinstimmen.

Das gleiche Prinzip gilt für Vorlagen und gemeinsame Referenzen. Wenn mehrere Fähigkeiten denselben Ausgabevertrag teilen, halten Sie eine autoritative Kopie bereit und lassen die anderen darauf verweisen. Zwingen Sie nicht zwei wirklich unterschiedliche Workflows durch ein einziges Hilfsprogramm zusammen, nur weil ihre ersten Beispiele ähnlich aussehen. Die Wiederverwendung sollte eine stabile Funktionsweise gewährleisten und nicht wichtige Unterschiede verbergen.

2. Hilfen Sie dem Agenten dabei, die richtige Fähigkeit auszuwählen

Durch progressive Disclosure beginnt ein Agent mit leichtgewichtigen Metadaten und lädt die vollständigen Anweisungen einer Fähigkeit erst dann, wenn er sich für diese entscheidet. Der praktische Grund dafür ist, dass das Vorladen aller Verfahren Ressourcen für Arbeiten bindet, die möglicherweise nie angefordert werden.

Bei der automatischen Auswahl dienen daher Name und Beschreibung als Leitinformationen. Die sorgfältig verfasste Erklärung weiter im Text ist möglicherweise sogar dann nicht verfügbar, wenn das Modell entscheidet, ob es die Datei öffnen soll.

Beschreibungen sind nicht die einzige Möglichkeit. Claude Code unterstützt auch explizite Aufrufe, und die Konfiguration zur Laufzeit beeinflusst, was verfügbar ist. Dennoch ist die Beschreibung das Auswahlsignal, das der Autor einer Fähigkeit steuern kann.

Ein Scan der Fähigkeitsbibliothek einer Person, wobei Namensdoppelte abgesehen von Kollisionen berücksichtigt wurden, ergab folgendes Resümee:

383 skills scanned
  missing description           0
  no trigger language         306
  colliding pairs               3
  duplicate names              23
  skills with >=1 defect      306  (79%)

Der Wert von 79 % entsteht durch eine gekürzte Berechnung von 306 geteilt durch 383, was etwa 79,9 % entspricht. Diese Beschreibungen haben eine Formulierungsprüfung nicht bestanden, was nicht dasselbe ist wie die 306 festgestellten Fälle, in denen eine Fähigkeit nicht verwendet wurde. Der Scanner überprüft nur wörtliche Auslöseformulierungen wie „verwenden, wenn“ oder „wenn der Benutzer“. Ein Modell kann einer Beschreibung ohne solche Wörter folgen, und eine Beschreibung mit ihnen kann dennoch zu allgemein sein, um hilfreich zu sein. Die Ausgabe ist eine Liste zur Untersuchung und kein Maß dafür, wie stark das Agent beschädigt ist.

Geben Sie benachbarten Fähigkeiten unterschiedliche Aufgaben

Betrachten Sie zwei tatsächliche Beschreibungen aus zwei Fähigkeiten im selben Plugin:

Einer von ihnen präsentiert sich als Experte für den Aufbau von Retrieval-augmented Generation-Systemen mit Vektordatenbanken, Embeddings und fortgeschrittenen Suchstrategien. Der andere präsentiert sich als Experte für die Auswahl, Konfiguration und Optimierung von Vektordatenbanken wie Pinecone, Weaviate, Chroma, Qdrant und Milvus für semantische Suche und RAG.

Beide klingen überzeugend – doch welcher eignet sich besser für einen Benutzer, der Hilfe bei der Auswahl einer Vektordatenbank für eine RAG-Anwendung benötigt? Ein leistungsstarkes Modell könnte dem zweiten, enger gefassten Ansatz den Vorzug geben, doch auch der erste behauptet, über dieselben Fähigkeiten zu verfügen. Da nicht klar ist, welche Fähigkeiten jeder besitzt, muss das Modell die Grenzen selbst ableiten.

Überarbeitungen in diesem Sinne würden eine klarere Trennung zwischen ihnen schaffen. Sie wurden bisher nicht verglichen:

name: vector-database-selection
description: >-
  Compare vector databases against workload, filtering,
  deployment, and operating-cost requirements. Use when
  choosing or replacing a vector store. For retrieval-pipeline
  design with an already chosen store, use rag-pipeline-design.

name: rag-pipeline-design
description: >-
  Design ingestion, chunking, retrieval, reranking, and
  evaluation for a RAG application. Use when building or
  diagnosing a retrieval pipeline. For a standalone vector
  database selection, use vector-database-selection.

Die erste übernimmt die Auswahl der Datenbank, die zweite die Aufgabe, aus Dokumenten einen nützlichen Kontext für eine Antwort zu erstellen. Ein Teil des Wortschatzes bleibt gemeinsam, da die Aufgaben tatsächlich überschneiden.

Entwerfen Sie die Testanfragen erst, bevor Sie an der Formulierung arbeiten. „Vergleichen Sie Vektorlagereinrichtungen für eine selbst gehostete Dokumentensuchanwendung“ bezieht sich auf die Auswahl der Datenbank. „Wo sollten unsere Embeddings gespeichert werden? Hilfen Sie mir bei der Entscheidung“ bedeutet dasselbe in anderen Worten. „Wir haben bereits ein Vektorlagereinrichtung, doch die Suche findet keine relevanten Abschnitte“ gehört zur Diagnose des Arbeitsablaufs.

Fügen Sie anschließend eine Anfrage hinzu, die keiner der beiden Fähigkeiten zugeordnet werden sollte, wie beispielsweise die Anpassung des Abstands eines Suchbuttons auf Mobilgeräten. Ohne diese Anfrage haben Sie nur getestet, welche der beiden Fähigkeiten überlegen ist, und nicht, ob der Agent beides ablehnen kann.

Probieren Sie sie in neuen Sitzungen mit dem identischen Modell, den aktivierten Fähigkeiten und dem Projektkontext aus. Lassen Sie den Namen der gewünschten Fähigkeit bei Tests zur automatischen Auswahl aus, da dies das Experiment verändert. Wenn die Laufzeit dies offenlegt, notieren Sie, welche Fähigkeit geladen wurde, und speichern Sie die erhaltene Antwort oder das erzeugte Ergebnis. Ein Protokoll, das das geöffnete Datei anzeigt, ist ein besseres Beweismittel als die Behauptung des Agenten, er habe die richtige Fähigkeit verwendet.

Vergleichen Sie die Ergebnisse vor und nach den Tests und halten Sie einige Paraphrasen außerhalb der Überarbeitungssitzung zurück, damit Sie nicht nur für Ihre eigenen Beispiele anpassen. Dieses kleine Regressionstest-Set zeigt an, ob eine Änderung bei wichtigen Anfragen geholfen hat.

3. Erfahrungen in wiederverwendbare Anweisungen umwandeln

Das Erkennen eines Problems führt zu einer nützlicheren Frage: Wo sollte die Korrektur erfolgen?

skill-repair schreibt seine Vorschläge als Diffs, die von einer Person zur Genehmigung vorgelegt werden, gegenüber einem unter Versionskontrolle stehenden Ziel. Ziel ist die kleinste Änderung, die das festgestellte Problem behebt, damit ein Prüfer sie lesen und zurücksetzen kann, falls sie etwas anderes beschädigt.

Stellen Sie sich eine Berichtserstellungsfähigkeit vor, die ohne Prüfung des Quelldokuments einen Zusammenfassung zurückgibt. Dem System zu sagen, es solle „vorsichtiger sein“, gibt dem Agenten nur sehr wenig Anhaltspunkte für Handlungen. Was die Lösung ist, hängt davon ab, warum die Überprüfung übersprungen wurde:

• Die Quelle wird im Verfahren nie benötigt: Ändern Sie das Verfahren.
• Die Quelle wird benötigt, aber ihre Lage wird nicht angegeben: Liefern Sie diesen Kontext oder fragen Sie nach dem fehlenden Eingang.
• Die Quelle wurde gelesen, aber eine Abbildung wurde falsch kopiert: Eine andere Überprüfung ist erforderlich.

Ein allgemeines Warnhinweis, der in jedem Fall eingefügt würde, würde die Diagnose völlig überspringen.

Behalten Sie die fehlgeschlagene Anfrage zusammen mit dem vorgeschlagenen Edit bei, beschreiben Sie das erwartete Verhalten und bewahren Sie das Artefakt auf, das den Fehler aufgedeckt hat. Führen Sie die Anfrage in einer neuen Sitzung erneut aus und versuchen Sie anschließend eine ähnliche Anfrage, die weiterhin funktionieren sollte. Andernfalls ist es einfach, eine Änderung zu genehmigen, weil sie überzeugend formuliert ist – was eine bequeme Art ist, einen Nachmittag zu verbringen, ohne etwas zu verbessern.

Auch der Umfang spielt eine Rolle. Eine Präferenz bezüglich eines Berichts bleibt bei diesem Bericht. Eine Regel für jeden Bericht, den die Fähigkeit erstellt, wird in die Fähigkeit selbst aufgenommen. Fakten, die sich häufig ändern, eignen sich besser für eine Referenz, die die Fähigkeit abruft. Wenn jede Korrektur in den dauerhaften Anweisungen landet, wird ein wiederverwendbares Verfahren allmählich zu einem Protokoll der letzten Sitzung einer Person.

Erfolge verdienen dieselbe Sorgfalt. Wenn eine Abfolge zuverlässig funktioniert, sollte die nützliche Reihenfolge sowie die Eingaben und Beispiele beibehalten werden – und nicht nur Warnungen darüber, was schiefgelaufen ist. Die Anleitung zur Erstellung von Agent Skills empfiehlt, Fähigkeiten in der praktischen Anwendung zu verankern und sie durch Ausführung weiter zu verfeinern. Eine Fähigkeit sollte das Wissen enthalten, das bei einem nächsten Ausführungsvorgang fehlt – nicht eine Aufzeichnung von allem, was geschehen ist.

Wenn der gemeinsame Leitfaden repariert werden muss

Die Bibliothek einer Person ist ihr eigener angesammelter Unordnungshaufen, der von ihrem eigenen Tool überprüft wird; daher wurde dieselbe Überprüfung auch auf ein öffentliches Plugin-Repository angewandt, das von einem Forschungs-Software-Team einer Universität betrieben wird. Im Snapshot enthielt es 76 Fähigkeiten in 12 Plugins.

Die Flags wurden nach Plugins gruppiert. Sieben Plugins wurden vollständig mit einem Flag versehen, und ein wissenschaftliches Python-Plugin wies vier von fünf Flaggen auf. Diese Gruppierung führte zu der Suche nach gemeinsamen Vorlagen und Konventionen, wobei sich die Beitragsanleitung als Quelle herausstellte. Sie forderte „eine klare Beschreibung des Agents und seines Zwecks“ und bot eine Platzhaltervorlage an, die angibt, was der Agent tut. Es wird dabei nie gefragt, wann er verwendet werden soll. 36 Anleitungen folgten der Anleitung korrekt, doch die Anleitung selbst enthielt einen Fehler.

Laut Berichten wurden zwei öffentliche Issues eröffnet, eines für die Anleitung und eines für die 36 Beschreibungen – und die Reihenfolge ist wichtig. Aktualisieren Sie zunächst die Konvention, zeigen Sie ein gutes Beispiel und bringen Sie erst danach die bestehenden Beschreibungen in Einklang. Andernfalls folgt der nächste Beitragssteller der Anleitung perfekt und führt dasselbe Muster erneut ein.

Eine CI-Prüfung kann helfen, sollte aber zunächst nur als Empfehlung genutzt werden. Wenn die Regel nur wenige Auslösephrasen kennt, führt ein strenger Fehler dazu, dass Mitwirkende diese Phrasen einfach einfügen, bis der Build erfolgreich ist – dadurch erhöht sich die Anzahl zwar, doch die Fähigkeiten der Nutzer verbessern sich nicht. Der eigentliche Akzeptanztest erfordert weiterhin repräsentative Anfragen, einschließlich solcher, die von der jeweiligen Fähigkeit ignoriert werden sollten.

4. Überprüfen vor der Weitergabe

verify-before-return stellt einer Fähigkeit Akzeptanzkriterien sowie einen Überprüfungszyklus zur Verfügung. Das Schreiben einer Datei auf die Festplatte ist nur ein Zwischenschritt – der Workflow muss das Ergebnis weiterhin anhand von für die Aufgabe geeigneten Belegen überprüfen:

• Bei Präsentationsfolien muss geprüft werden, ob diese korrekt dargestellt werden, ob Texte abgeschnitten sind, Etiketten unleserlich sind oder Elemente außerhalb des Bildschirms liegen.
• Bei Forschungsberichten müssen die Quellen geöffnet und überprüft werden, ob sie die darin gemachten Behauptungen stützen.
• Bei Code müssen Tests ausgeführt werden, die das erforderliche Verhalten überprüfen.

Jede Behauptung, die Arbeit sei abgeschlossen, sollte auf das verweisen, was tatsächlich überprüft wurde.

Definieren Sie diese Kriterien vor der Erstellung. Lassen Sie anschließend das Modell einen Entwurf erstellen, Fehler überprüfen und beheben sowie die durch die Korrekturen betroffenen Checks erneut durchführen. Begrenzen Sie den Überarbeitungskreislauf und verlangen Sie eine Offenlegung aller noch ungelösten Probleme, denn „ständige Verbesserung“ kann sonst zu endlosem Bearbeiten ohne klareres Ergebnis werden.

Subjektive Arbeiten erfordern eine andere Art der Überprüfung. Ein simulierter Anfänger kann unerklärliche Begriffe markieren, und ein skeptischer Leser kann die Argumentation in Frage stellen. Beides ist nützlich, doch es handelt sich dabei um kritische Anmerkungen des Modells und nicht um Feedback von echten Zuschauern; daher sollten Sie jeden Vorschlag im Verhältnis zum Zweck des Werkes bewerten, anstatt alle Einwände zu akzeptieren. Die Beurteilung von Geschmack und Strategie bleibt bei dem, der die Arbeit in Auftrag gegeben hat.

Das Durchführen einer Überprüfung ist nicht dasselbe wie das Durchführen der richtigen Überprüfung – und die eigenen Tests des Prüfers zeigen, warum.

Welche Tests der Prüfer geändert hat

Die Tests zeigten, dass der Prüfer doppelte Installationen sowie überschneidende Beschreibungen als separate Befunde behandeln musste. Die erste Durchführung ergab 81 mögliche Paare, von denen viele identische Fähigkeiten in verschiedenen gespeicherten Plugin-Versionen waren. Die Betrachtung dieser Paare führte dazu, dass doppelte Einträge mit demselben Namen aus der Kollisionsanalyse ausgeklammert wurden, wodurch die Anzahl der möglichen Paare auf 3 sank.

Deshalb sollten die hinter einer Zusammenfassung stehenden Datensätze vor jeglicher Änderung überprüft werden. Doppelte Dateien erfordern eine Inventurprüfung, während konkurrierende Beschreibungen einen Routentest benötigen. Ihr Zusammenfassen führt dazu, dass die Menschen zur falschen Lösung gelenkt werden.

Durch die Trennung doppelter Namen kamen außerdem 23 Namen zum Vorschein, die an mehr als einem gescannten Pfad vorhanden waren. Gecachte Kopien beweisen nicht, dass alte Versionen aktiv waren – dazu muss man die aktivierten Plugins sowie die gelösten Pfade überprüfen. Ebenso zählen 383 Dateien, die nicht aktiv sind, sowie einzigartige Fähigkeiten; die Ausklammerung von Vergleichen mit denselben Namen beseitigt nicht das gesamte Doppelte im Inventar.

Die Bewertung ist lediglich eine heuristische Formulierung: Die gemeinsamen Wörter beider Beschreibungen geteilt durch die unterschiedlichen Inhaltswörter, wobei 0,35 als Standardschwelle gilt. Eine Ausklammerung kann wie eine Überschneidung aussehen, und zwei unterschiedlich formulierte Beschreibungen derselben Aufgabe können durchrutschen. Der Frontmatter-Parser unterstützt außerdem nur einen Teilbereich von YAML. Jedes Flag benötigt eine menschliche Überprüfung, bevor es zu einer Korrektur führt.

Wenn eine Reparatur erfolgreich ist, bewahren Sie den fehlerhaften Fall zusammen mit einem auf, bei dem die alte Version bereits korrekt funktioniert hat. Gemeinsam zeigen sie an, ob eine spätere Änderung ein Verhalten behebt, indem sie ein anderes stört. Für whetstone wurde keine allgemeine Verbesserung der Aufgabenerfolgsrate festgestellt, und durch diese Überprüfungen würde sie bewertet.

Die Verpackung reist nicht; die Fähigkeiten schon

Eines der Ziele war es, whetstone auch außerhalb von Claude Code nutzbar zu machen. Das Teilen des SKILL.md-Formats bringt dabei einen Schritt weiter. Eine Fähigkeit kann dennoch auf Tools, Berechtigungen oder Dateipfaden angewiesen sein, die ein anderer Client nicht bereitstellt, und jeder Client packt die Plugins unterschiedlich zusammen. Der Agent Plugins-Standard, die Claude Code-Dokumentation sowie die OpenCode-Dokumentation beschreiben diese Strukturen.

Whetstone versendet beide Manifeste über einen einzigen gemeinsamen skills/-Ordner. Das Verfahren wird an einem Ort gespeichert, und die Integration jedes Clients wird separat getestet. Portable Anleitungen machen die Modelle dennoch nicht austauschbar, daher sollten Sie dieselbe repräsentative Aufgabe auf einem anderen kompatiblen Laufzeitumfeld ausführen und dessen Werkzeugaufrufe, Abhängigkeiten sowie Ausgabe überprüfen, bevor Sie annehmen, das Verhalten sei identisch.

Testen in einem Workflow

Es ist keine umfangreiche Bibliothek erforderlich. Wählen Sie einen Workflow – beispielsweise einen Helfer, den der Agent ständig neu erstellt, zwei Fähigkeiten, die er miteinander kombiniert, oder eine Ausgabe, die Sie üblicherweise manuell abschließen. Behalten Sie eine repräsentative Anfrage sowie deren Ergebnis zur Vergleichszweck bei.

Dann wählen Sie die geeignete Maßnahme aus: einen vorhandenen Hilfsprogramm wiederverwenden, die Auswahl präzisieren, eine schrittweise Anleitung aufzeichnen oder eine fehlende Überprüfung hinzufügen. Vergleichen Sie anschließend den folgenden Ausführungsvorgang mit dem gespeicherten Beispiel. Ein umfassenderes Inventar kann warten, und ein alter Cache sollte nicht einfach deshalb gelöscht werden, weil eine rekursive Suche alte Dateien aufgefunden hat.

Das Projekt wird unter einer MIT-Lizenz bereitgestellt. Für Claude Code geben die dazugehörigen README-Dateien folgende Installationsbefehle an:

claude plugin marketplace add cdcore09/whetstone
claude plugin install whetstone@whetstone

Vier Eingangspunkte sind verfügbar: /audit, /promote, /repair und /verify. Verwenden Sie denjenigen, der am besten zum jeweiligen Workflow passt. Beim ersten Versuch ist es ratsam, dass er die relevanten Dateien überprüft und Änderungsvorschläge macht, bevor etwas angewendet wird.

Um den Auditor ohne Installation zu untersuchen, klonen Sie das Repository und lesen Sie skills/skill-audit/scripts/audit_skills.py. Von der obersten Ebene des Repositoriums aus wird mit dem untenstehenden Befehl der Auditor gestartet, wobei ausschließlich die Standardbibliothek von Python verwendet wird:

python3 skills/skill-audit/scripts/audit_skills.py ./skills

Ersetzen Sie ./skills durch den Verzeichnisort, den Sie untersuchen möchten – beginnen Sie mit einer kleinen Sammlung, die Sie erkennen, bevor Sie jeden Plugin-Cache auf Ihrem Rechner durchscannen. --json liefert einen strukturierten Bericht, und --threshold 0.25 zeigt eine breitere Auswahl an überschneidenden Beschreibungen.

Das Skript liest nur Dateien ein und schreibt die Informationen niemals neu. Ein Abbruchstatus von 1 bedeutet, dass Flaggen, Kollisionsfälle zwischen Kandidaten oder doppelte Namen gefunden wurden – das ist jedoch nicht automatisch ein Absturz von Python. Die Standardverzeichnisse umfassen außerdem nicht die Installationsstruktur jedes Clients; daher macht ein expliziter Pfad den Umfang klarer und erleichtert die Nachvollziehbarkeit. Falls der Bericht private Beschreibungen von Fähigkeiten oder Dateisystempfade enthält, lagern Sie ihn lokal ab und teilen Sie stattdessen nur Zahlen sowie anonymisierte Beispiele anstelle einer Aufstellung interner Projekte.

Das Ziel ist es, nützliche Ergebnisse anzuhäufen: Code, der wiederverwendet werden kann, Verfahren, die überprüft werden können, sowie Kontrollmechanismen, die mit der Aufgabe mitgegeben werden. Das ist ein praktischer Einstiegspunkt für sich selbst verbessernende Agenten, der außerdem unter Versionskontrolle bleibt. Jeder, dessen Arbeitsablauf eine andere Implementierung erfordert, kann anhand von vier Fragen vorgehen: Was soll wiederverwendet werden, was soll ausgewählt werden, was soll gelernt werden und wie soll das Ergebnis überprüft werden.