Der Skill-Reflex

Skills sind gerade (wieder) überall. Cursor hat seine Rules-Files^[01], GitHub Copilot liest copilot-instructions.md^[02], OpenAI und Google schreiben gemeinsam am offenen AGENTS.md-Standard^[03], und Anthropic hat das Konzept mit Claude Skills in ein formales Feature-Format gegossen^[04]. Die Idee ist bei allen dieselbe: ein Stück Text, das dem Modell vorab sagt, wie es sich verhalten soll. Auf LinkedIn erklären dir Agenturen täglich, warum du welche brauchst. Marketplaces mit fertigen Packs gibt es inzwischen auch.

Wir bauen selbst welche. Für Kundenprojekte, interne Tools, eigene Produkte. Die wichtigste Erkenntnis aus dieser Arbeit ist nicht, wie man gute Skills baut — sondern wann man es lässt.

Skills sind vorab formulierte Annahmen. Und Annahmen altern schneller, als sie gepflegt werden. Jede Regel, die nicht mehr zum konkreten Fall passt, wird zur Qualitätsbremse. Der Skill zwingt dem Modell ein Muster auf, das vielleicht gestern noch richtig war, und das Ergebnis liest sich entsprechend.

Skills ersetzen häufig genau das, was LLMs von sich aus schon gut können. Für dokumentierte Formate und etablierte Patterns ist das Trainingswissen solide. Der Skill wiederholt dann nur, was im Modell ohnehin steckt — und nimmt dabei den Spielraum sich im konkreten Fall anders zu entscheiden.

Das technische Problem

Der Kern liegt tiefer, als die meisten vermuten. Der Begriff “Skill” bedeutet je nach Anbieter unterschiedlich viel: Bei den meisten Systemen sind es reine Textanweisungen im Markdown-Format, bei manchen kommen ausführbare Skripte dazu, die Fähigkeiten tatsächlich erweitern. Dieser Code-Teil ist unproblematisch, weil er das Modell befähigt, etwas zu tun, das es vorher nicht konnte — saubere Dokumente generieren, eigene APIs ansprechen, Daten validieren. Der kritische Teil ist das, was bei allen Systemen gleich funktioniert: die Prompt-Anweisungen. Sie verändern das Modell nicht, bleiben jedoch Kontext, der in jeder Inferenz mit dem User-Prompt um Aufmerksamkeit konkurriert.

Stanford-Forscher haben mit ihrem viel zitierten Lost-in-the-Middle-Paper gezeigt, dass LLMs Informationen in der Mitte langer Kontexte schlechter verarbeiten als am Anfang oder Ende — die Performance kann um über 30 Prozent einbrechen^[05]. Chromas neuere Context-Rot-Research bestätigt den Befund: Je länger der Kontext, desto unzuverlässiger die Nutzung einzelner Informationen^[06]. In der Praxis heißt das: Skills wirken bei kurzen Aufgaben stark und bei langen, komplexen Aufgaben oft schwächer als erwartet. Also genau umgekehrt zum tatsächlichen Bedarf.

Wann sich ein Skill lohnt — und wann nicht

Die Faustregel ist einfach: Ein Skill ist dann gerechtfertigt, wenn er etwas festhält, was das Modell nicht wissen kann. Das betrifft vor allem umgebungsspezifische Konventionen wie Brand Voice, interne Libraries oder firmeneigene Prozesse. Ebenso Code und Tools, die echte Fähigkeiten ergänzen — saubere Dokumentgenerierung, eigene Datenquellen, validierte Formatprüfung. Dazu kommen harte Grenzen, die nicht verhandelbar sind (Compliance, rechtliche Vorgaben), sowie wiederkehrende Aufgaben, bei denen sich der Wartungsaufwand rechnet und Ergebnisse über viele Aufrufe hinweg reproduzierbar bleiben müssen.

Alles andere ist Ballast. Allgemeine Qualitätsregeln wie “schreib klar” oder “strukturiere sauber” kann das Modell ohnehin — der Skill wiederholt nur, was im Training schon drin ist. Seltene oder einmalige Aufgaben rechtfertigen keinen Wartungsaufwand. Bei Ideenfindung, Prototyping oder Kreativarbeit ist ein Skill fehl am Platz, weil genau die Varianz verloren geht, die in diesen Aufgaben das Wesentliche ist. Und Regeln, die genauso gut in den User-Prompt gehören, gehören genau dahin.

Regeln für Skills, die sich bewähren

Wer trotzdem einen baut, sollte ein paar Prinzipien einhalten. Der wichtigste: so kurz wie möglich, jeder Absatz muss gerechtfertigt sein. Konkrete Beispiele schlagen abstrakte Prinzipien, weil Modelle aus Beispielen besser lernen als aus Regelwerken. Ownership klar festlegen, denn ein Skill ohne Besitzer verwildert innerhalb weniger Monate. Und regelmäßig stresstesten: Wird das Ergebnis ohne den Skill wirklich schlechter? Wann wurde er zuletzt überarbeitet? Nur so kann sichergestellt werden, dass ein Skill auch einen echten Mehrwert schafft.

Ihre Aufgabe beschränkt sich auf Orientierung bei Dingen, die das Modell nicht von alleine wissen kann. Wer einen Skill nie reduziert, hat nach ein paar Monaten meistens ein Regelwerk, das die Stärken des Modells ausbremst statt sie zu nutzen.

Viele Skill-Bibliotheken entstehen weniger aus echtem Qualitätsbedarf als aus dem Bedürfnis, Kontrolle über ein System zu haben, das sich Kontrolle von Natur aus entzieht. Das ist menschlich verständlich, aber es erklärt ganz gut, warum der Markt gerade so aussieht, wie er aussieht: voll mit Packs, Marketplaces und Agenturen, die alle dasselbe Bedürfnis bedienen.

Gute Skills zu bauen heißt vor allem, diesem Reflex zu widerstehen.