Beim Claude Code Anonymous am Dienstag saßen zwölf Leute im Stuhlkreis bei c-trace in Bielefeld. Ich habe die Frage wieder gestellt: Wer hat seit dem letzten Mal einen eigenen Skill gebaut?
Drei Hände.
Im Juni hatten zwei von 22 einen eigenen Sub-Agent definiert. Die Quote bewegt sich, aber langsam. Das sind Entwickler, die Claude Code, Codex oder Pi täglich benutzen und an einem Dienstagabend freiwillig über Harnesses reden. Dass Entwickler die Tools nutzen, aber die Konzepte dahinter kaum kennen, ist in Teams die Regel.
Eine zweite Beobachtung kam auf, ohne dass ich danach gefragt hatte. In der Runde fiel immer wieder das Wort „Amnesie“: Wenn das Kontextfenster voll ist, befolgt der Agent Anweisungen vom Anfang nicht mehr. Das Muster kenne ich aus meiner eigenen Arbeit. Auch andere erfahrene Entwickler, die mit KI-Tools arbeiten, berichten regelmäßig davon: Der Agent arbeitet eine Weile gut, dann läuft das Fenster voll, das Werkzeug komprimiert die Sitzung, und danach fehlt ein Teil. Regeln, die ich am Anfang erklärt habe, sind weg. Ich erkläre sie nochmal. Beim nächsten Mal wieder. Das ist Teil der Frustration mit den Tools.
Die beiden Beobachtungen gehören zusammen.
Die Kartenwand beim Claude Code Anonymous am 8. September 2026 bei c-trace in Bielefeld.
Was bei der Kompression verloren geht
Alles, was du dem Agenten im Chat erklärst, lebt im Kontextfenster. Das Fenster ist endlich. Läuft es voll, wird komprimiert, und Kompression ist verlustbehaftet. Was dabei wegfällt, entscheidest nicht du.
Eine Datei auf der Platte fällt nicht weg. Der Agent kann sie wieder lesen, so oft er will, in jeder Sitzung, nach jeder Kompression.
Ein Skill ist genau das: ein Ordner mit einer SKILL.md. Im Dateikopf stehen name und description, darunter folgt die Anleitung in Prosa. Daneben können Skripte und Referenzdateien liegen. Anthropic beschreibt das Format in der Dokumentation, und seit Dezember 2025 ist es ein offener Standard, den Codex, Cursor, Pi und andere Harnesses ebenfalls lesen.
Der Mechanismus, der gegen die Amnesie hilft, heißt Progressive Disclosure. Beim Start liegen nur name und description im Kontext, etwa hundert Token pro Skill. Der Text der Anleitung wird erst geladen, wenn eine Aufgabe zur Beschreibung passt. Skripte laufen über die Shell, ihr Code landet nie im Fenster, nur ihre Ausgabe. Anthropic erklärt das in Equipping agents for the real world with Agent Skills.
Für die Amnesie heißt das: Die Anleitung kostet fast nichts, solange sie nicht gebraucht wird. Und wenn sie nach einer Kompression fehlt, holt der Agent sie sich beim nächsten passenden Auftrag wieder von der Platte. So musst du dieselbe Anleitung nicht nochmal in den Chat schreiben.
Statisch oder dynamisch
Die meisten Teams, die ich sehe, haben bereits eine CLAUDE.md oder AGENTS.md. Das ist die richtige erste Stufe, ich habe sie im Beitrag zu Malleable Software beschrieben. Nur: Diese Datei ist statischer Kontext. Sie liegt in jedem Turn im Fenster, ob die Aufgabe sie braucht oder nicht. Jede Regel, die du dort ergänzt, belegt zusätzlichen Platz im Fenster, sodass früher komprimiert werden muss.
Das Google-Papier The New SDLC With Vibe Coding (Osmani, Saboo, Kartakis, 2026) unterscheidet zwischen statischem und dynamischem Kontext und nennt Skills als Muster für den dynamischen Teil. Die Autoren zählen vier Probleme auf, die Skills lösen: Qualitätsverlust durch überladene Prompts, fehlendes Gedächtnis für Arbeitsabläufe, zusätzlicher Aufwand beim Zusammenspiel mehrerer Agenten und mangelnde Übertragbarkeit zwischen Werkzeugen. Die ersten beiden sind die Amnesie aus dem Stuhlkreis.
Die Faustregel: In die CLAUDE.md gehört, was in jeder Sitzung gilt. Alles, was nur bei bestimmten Aufgaben gilt, gehört in einen Skill.
Warum bauen dann so wenige?
Meine Vermutung nach fünf Treffen: Bei der Frage „Was ist einen Skill wert?“ denken viele gleich an ein Framework. Man will etwas Wiederverwendbares bauen, etwas Sauberes, und weil das Aufwand ist, baut man nichts.
Das Kriterium ist einfacher. Wenn du einem Agenten zum dritten Mal dasselbe erklärst, lohnt sich dafür ein Skill. Der Text steht schon in deinem Chatverlauf. Du musst ihn nur in eine Datei kopieren und oben eine Beschreibung schreiben, die sagt, wann sie gilt.
Für den Kopf der Datei gibt es Werkzeuge. Anthropic liefert einen skill-creator mit, der Frontmatter, Struktur und eine erste Testrunde übernimmt. Die Syntax musst du nicht lernen, die ändert sich sowieso. Was bleibt, ist die Entscheidung, welche Erklärung du nicht zum vierten Mal tippen willst.
Mit einem solchen Skill-Creator kann der Agent auch selbst vorschlagen, eine wiederkehrende Anleitung als Skill festzuhalten.
Ich rate dazu, mit fünf bis zehn klar abgegrenzten Skills anzufangen. Einer für den Build in diesem Projekt. Einer für die Commit-Konvention. Einer für den Ablauf, mit dem du eine Migration schreibst. Verallgemeinern kannst du später, wenn du siehst, welche davon du wirklich benutzt. Was sich nicht bewährt, kannst du wegwerfen oder neu schreiben.
Der Einwand: Zu viele Skills
Ein naheliegender Einwand: Eine große Sammlung verwirrt den Agenten. Dazu gibt es Zahlen. Jiang et al. haben in Demystifying Agent Skills gemessen, was passiert, wenn der Pool von 5 auf 100 Skills wächst: Der Anteil der Fälle, in denen der Agent den richtigen Skill benutzt, fällt von rund 30 auf 3 Prozent. Die Erfolgsquote der Aufgaben bleibt aber etwa gleich, weil der Agent auch aus ähnlichen Skills brauchbare Teile zieht.
Problematisch sind vor allem Skills, deren Beschreibungen sich kaum unterscheiden. Schreib die description so, dass auch jemand ohne Projektkenntnis entscheiden könnte, wann der Skill passt. Leg zwei Skills zusammen, wenn du sie selbst nicht auseinanderhalten kannst.
Weiter am 13. Oktober
Am 13. Oktober treffen wir uns wieder, diesmal bei comspace. Ich stelle die Frage nochmal. Bis dahin: Nimm die Erklärung, die du nach der letzten Kompression wiederholt hast, und leg sie als SKILL.md ab. Zeig uns beim nächsten Treffen in fünf Minuten, wie du damit arbeitest. Code und Prompt reichen.