Als Softwareentwickler habe ich jahrelang gelernt: Don‘t Repeat Yourself. Duplizierter Code ist ein Wartungsproblem. Abstraktionen sparen Arbeit. Was einmal funktioniert, wird extrahiert, parametrisiert und wiederverwendet.
Bei Skills, System Prompts und Agentenspezifikationen funktioniert diese Intuition nicht. Genauer: Sie schadet.
Das DRY-Reflex-Problem
Wenn du zum ersten Mal einen Skill für Claude Code schreibst – sagen wir, einen Skill, der aus Stichpunkten ein strukturiertes Meeting-Protokoll erzeugt – liegt der Reflex nahe, ihn sofort allgemeingültig zu machen. Ein Meeting-Protokoll-Skill, der überall funktioniert. Parametrisiert, konfigurierbar, für jedes Projekt nutzbar.
Das Problem: Du weißt nach dem ersten Skill noch gar nicht, was „gut“ bedeutet.
Du weißt nicht, welche Formulierungen im Prompt den Unterschied machen. Du weißt nicht, welche Constraints für Projekt A wichtig sind, aber für Projekt B irrelevant. Du weißt nicht, ob der Skill besser wird, wenn du ihn kürzer machst oder ausführlicher. Und du weißt nicht, wie sich das Ergebnis verändert, wenn nächsten Monat ein neues Modell kommt.
Trotzdem investierst du Zeit in Generalisierung. Du baust Variablen ein, schreibst Dokumentation, überlegst dir eine Ordnerstruktur. Und am Ende hast du einen Skill, der überall ein bisschen funktioniert und nirgendwo richtig gut ist.
Wegwerfprodukte statt Bibliotheken
Mein Ansatz ist ein anderer geworden. Ich behandle Skills, System Prompts und Agentenspezifikationen als Wegwerfprodukte.
Wenn ich in einem neuen Projekt einen Skill brauche, generiere ich ihn neu. Nicht kopiert, nicht importiert. Neu generiert, angepasst an den Kontext, an die Codebasis, an die Aufgabe. Das dauert mit einem guten Skill Creator wenige Minuten. Manchmal ist der erste Wurf gut genug. Manchmal braucht es zwei oder drei Iterationen.
Nach fünf bis zehn ähnlichen Skills in verschiedenen Projekten passiert dann etwas Interessantes: Ich sehe die Muster. Nicht theoretisch, sondern aus echten Ergebnissen. Welche Formulierung zuverlässig funktioniert. Welcher Constraint sich bewährt hat. Welche Struktur der Agent am besten verarbeitet. Und welche Teile ich jedes Mal anders mache, weil sie vom Kontext abhängen.
Erst an diesem Punkt lohnt sich Generalisierung. Nicht vorher.
Warum das für Entwickler so schwer ist
Für jemanden, der seit Jahren sauberen, wartbaren Code schreibt, fühlt sich das falsch an. Wir sind trainiert, Duplikation zu vermeiden. Wir sehen zwei ähnliche Dateien und wollen sie zusammenführen. Wir sehen einen funktionierenden Prompt und wollen ihn in eine Bibliothek stecken.
Aber Skills sind kein Code.
Code hat eine klare Semantik. Wenn eine Funktion zweimal dasselbe tut, kann ich sie extrahieren, und das Verhalten bleibt identisch. Bei einem Prompt ist das nicht so. Kleine Änderungen in der Formulierung – ein Satz mehr Kontext, eine andere Reihenfolge der Anweisungen, ein weggelassener Constraint – können das Ergebnis grundlegend verändern. Die Beziehung zwischen Input und Output ist nicht deterministisch. Sie hängt vom Modell ab, vom Kontext, von der konkreten Aufgabe.
Das bedeutet: Zwei Skills, die ähnlich aussehen, können in der Praxis sehr unterschiedlich funktionieren. Und ein Skill, der in Projekt A brilliert, kann in Projekt B mittelmäßig sein, weil der Kontext ein anderer ist.
Skills sind so leicht zu erstellen, dass Generalisierung sich nicht lohnt
Es gibt noch ein pragmatisches Argument. Skills zu erstellen ist billig. Nicht billig im Sinne von „egal“, sondern billig im Sinne von „der Aufwand für Neuerstellung ist geringer als der Aufwand für Wartung einer generalisierten Version“.
Wenn du einen Skill in drei Minuten generieren kannst, der für dein aktuelles Projekt passt, warum solltest du zwanzig Minuten investieren, um einen generalisierten Skill zu pflegen, der in jedem Projekt erst angepasst werden muss?
Die Rechnung kippt erst, wenn du so viele Projekte bedienst, dass die Erstellungszeit wirklich ins Gewicht fällt. Für die meisten Teams und Einzelentwickler ist das nicht der Fall.
Dasselbe Prinzip greift bei System Prompts, Agentenspezifikationen und Kommandos. Überall dort, wo natürliche Sprache als Steuerungsmechanismus dient, gelten andere Regeln als bei Code.
System Prompts veralten mit jedem Modellwechsel. Was für Claude Sonnet 4.5 gut formuliert war, braucht für Opus 4.7 vielleicht eine andere Struktur. OpenAI hat bei GPT 5.5 explizit empfohlen, es als neue Modellfamilie zu behandeln, nicht als Drop-in-Replacement. Das gilt nicht nur für API-Aufrufe. Es gilt für jeden Prompt, jeden Skill, jede Agentenspezifikation.
Wenn du deine Prompts als Bibliothek pflegst, hast du nach zwei Modellgenerationen eine Bibliothek voller veralteter Artefakte, die du alle einzeln testen und aktualisieren musst. Wenn du sie als Wegwerfprodukte behandelst, generierst du sie einfach neu — mit dem aktuellen Modell, für den aktuellen Kontext.
Der Moment, in dem Generalisierung Sinn ergibt
Irgendwann ergibt Generalisierung natürlich Sinn. Aber der Zeitpunkt ist später, als die meisten Entwickler denken.
Meine Faustregel: Erst nach fünf bis zehn Varianten in verschiedenen Projekten. Dann hast du genug Datenpunkte, um zu sehen, was stabil ist und was variiert. Du kannst die stabilen Teile extrahieren und die variablen Teile als Parameter oder als Kontext-Hooks gestalten. Das Ergebnis ist ein Skill, der auf echten Erfahrungen basiert, nicht auf Annahmen.
Vorher generalisierst du Vermutungen. Danach generalisierst du Wissen.
Ich arbeite an vielen verschiedenen code-bases und habe einen Mix aus wenigen allgemeinen Skills und einem Repo an Vorlagen, die ich in Projekten neu instanziiere und anpasse, um zum tech stack und Workflow zu passen. Quasi das Template Design Pattern, angewandt auf Skills statt Code.
Was das für Teams bedeutet
Wenn du in deinem Team Skills oder Prompt-Bibliotheken einführen willst, würde ich folgenden Weg empfehlen:
Lasst jeden erst einmal eigene Skills schreiben. Für seine Projekte, für seine Aufgaben, in seinem Kontext. Ohne die Auflage, dass die Skills teamweit funktionieren müssen. Das senkt die Einstiegshürde und liefert sofort Ergebnisse.
Nach ein paar Wochen schaut ihr euch an, was entstanden ist. Welche Muster tauchen auf? Welche Formulierungen funktionieren zuverlässig? Welche Teile sind projektspezifisch, welche übertragbar? Aus diesem Material könnt ihr dann Team-Skills destillieren, die auf echtem Gebrauch basieren.
So habe ihr im Team quasi ‚distributed skill evals‘, also dezentrale Skills, die sich im Wettbewerb zueinander durchsetzen.
Das ist langsamer als „einmal einen guten Skill schreiben und an alle verteilen“. Aber es führt zu Skills, die tatsächlich funktionieren, statt zu Skills, die theoretisch gut aussehen und in der Praxis von niemandem benutzt werden.
Und wenn das nächste Modell-Update kommt, generiert ihr die nächste Runde. Ohne schlechtes Gewissen: Denn die alten Skills waren nie als Dauerlösung gedacht.