Ihre KI-Skills brauchen Versionskontrolle

Blog · 6 Min. Lesezeit

Vor den Paketmanagern hieß „fremden Code benutzen“, eine Datei ins eigene Projekt zu kopieren. Das funktionierte — bis das Original einen Fehler behoben bekam und Ihre Kopie nicht, oder bis Ihre Kopie gerade so weit abgewichen war, dass das Zurückführen der Korrektur kein Copy-and-paste mehr war. Für Code haben wir das vor Jahrzehnten gelöst. Skills durchleben gerade genau dasselbe Problem, und meist ohne die Lösung.

Fragen Sie herum, und Sie finden überall dasselbe Muster: Ein guter Prompt für Pull-Request-Reviews wird in Projekt A eingefügt, dann noch einmal in Projekt B, weil er dort auch gut funktionierte, dann ein drittes Mal mit zwei geänderten Zeilen für eine andere Sprache. Das ist kein Skill mehr. Das sind drei Prompts mit gemeinsamem Vorfahren und ohne Möglichkeit, ein halbes Jahr später zu sagen, welcher „der echte“ ist oder ob die Korrekturen an A jemals bei C angekommen sind.

Was Copy-and-paste Sie tatsächlich kostet

• Korrekturen verbreiten sich nicht. Find a mistake in the shared logic and you have to remember every place you pasted it, then go fix each one by hand.
• Es gibt kein Diff. When two copies disagree, you can't tell what changed on purpose versus what someone forgot to update.
• Es gibt kein Rollback. A change that turns out to be wrong has already overwritten the version that worked.

Nichts davon spricht dagegen, Skills aus anderen Skills zusammenzusetzen — eine Testphilosophie über fünf sprachspezifische Skills hinweg zu teilen oder einen Hausstil über ein Dutzend spezialisiertere, ist genau die Art von Wiederverwendung, die sich lohnt. Es spricht dafür, dass diese geteilten Teile dieselbe Disziplin bekommen wie Code-Abhängigkeiten: eine echte Version, eine deklarierte Bedingung und einen Ort, an dem „aktuell“ etwas bedeutet.

Das Paketmanager-Modell, auf Anweisungen angewandt

Behandeln Sie einen Skill als Paket statt als Textblock, und die ganze Problemklasse verschwindet — genauso wie beim Code:

• Ein Skill hat eine Version. Ändern Sie ihn, und die Version ändert sich mit.
• Ein anderer Skill kann mit einer Bedingung (>=1.0.0) davon abhängen, statt seinen Inhalt einzubetten.
• Eine Aktualisierung der Abhängigkeit zu veröffentlichen, aktualisiert jeden abhängigen Skill, der sie auflöst — kein Aufspüren von Kopien.
• Eine Version kann als veraltet markiert werden, ohne das zu brechen, was noch auf sie festgelegt ist.
• Absichtliches Abweichen ist ein Fork, als solcher festgehalten, und kein unverfolgtes Copy-and-paste.

Das ist dieselbe Form wie npm, pip oder cargo — nicht weil Skills Code wären, sondern weil „viele Dinge hängen von einer gemeinsamen Sache ab, die sich über die Zeit ändert“ dasselbe Problem ist, ganz gleich was in der Datei steht.

Ein Skill, der nur als eingefügter Text existiert, hat keine Herkunft. Ein versionierter, komponierbarer Skill hat eine Geschichte, über die man tatsächlich nachdenken kann.

Ausprobieren

Das Tutorial Compose and version skills like code zeigt, wie Sie eine Abhängigkeit deklarieren, eine Aktualisierung veröffentlichen, die jeder abhängige Skill übernimmt, und einen Skill forken, ohne den Ursprung aus den Augen zu verlieren.