Stellen Sie sich vor, Sie hätten gerade einen superintelligenten, unglaublich schnellen Roboter-Assistenten in Ihr Zimmer eingeladen, um Ihnen beim Bau eines Baumhauses zu helfen. Dieser Roboter weiß alles über Holz, Nägel und Physik, aber er kennt nicht Ihren spezifischen Stil. Er weiß nicht, dass Sie das Geländer immer blau streichen oder dass Sie eine seltsame Regel haben, niemals Nägel zu verwenden, die kürzer als zwei Zoll sind. Wenn Sie möchten, dass der Roboter das Baumhaus genau nach Ihren Vorstellungen baut, müssen Sie es ihm sagen. Aber wenn Sie jedes noch so kleine Detail jedes Mal erklären müssen, wenn Sie um Hilfe bitten, werden Sie erschöpft sein und der Robot könnte verwirrt werden.

Dies ist die Welt der „KI-Agenten“ – intelligente Computerprogramme, die Aufgaben für uns erledigen können. Um sie wirklich hilfreich zu machen, geben Entwickler ihnen „Skills“ (Fähigkeiten). Betrachten Sie einen Skill nicht als Zauberspruch, sondern als eine kleine Bedienungsanleitung oder ein Werkzeugset, das Sie dem Roboter in die Hand drücken. Es ist eine Datei, die besagt: „Hey, wenn du eine Aufgabe wie diese siehst, ist hier genau festgelegt, wie ich möchte, dass du sie ausführst.“ Die große Frage, die Wissenschaftler und Ingenieure sich stellen, lautet: Wie schreiben wir diese Anleitungen so, dass der Roboter sie auch tatsächlich befolgt? Wenn wir sie schlecht schreiben, ignoriert der Roboter sie vielleicht oder erledigt die Aufgabe falsch. Wenn wir sie gut schreiben, wird der Roboter zu einem echten Experten für Ihre spezifische Arbeitsweise.

Das Papier, das Sie gleich lesen werden, verfasst von Giuseppe Destefanis, argumentt, dass das Schreiben dieser „Skills“ nicht wie das Schreiben einer lockeren Notiz oder eines Gedichts behandelt werden sollte. Stattdessen sollte es wie Software Engineering behandelt werden. Genau wie ein Programmierer eine zuverlässige App mit klaren Regeln, sauberem Code und Sicherheitsprüfungen baut, sollten wir KI-Skills mit derselben Sorgfalt erstellen. Das Papier schlägt vor, dass ein Skill eigentlich ein getarntes Stück Software ist. Er hat eine „Schnittstelle“ (ein Label, das sagt, was er tut) und eine „Implementierung“ (die eigentlichen Anweisungen). Der Autor schlägt vor, dass wir dieselben strengen Regeln verwenden sollten, die wir beim Bau von Computerprogrammen anwenden – wie etwa die Dinge einfach zu halten, das „Was“ vom „Wie“ zu trennen und sie sorgfältig zu testen –, um sicherzustellen, dass unsere KI-Agenten nicht vom Weg abkommen.

Der „Skill“ als digitales Schweizer Taschenmesser

Stellen Sie sich vor, Sie haben einen riesigen, magischen Rucksack, der alles aufnehmen kann. Darin haben Sie eine spezielle Tasche für „Erstellung von Release Notes“. Diese Tasche ist nicht nur ein Stück Papier; sie ist ein ganzes Kit. Sie hat ein Etikett auf der Außenseite, das sagt: „Verwende mich, wenn du eine Zusammenfassung der Änderungen für eine neue Version eines Spiels erstellen musst.“ Dieses Etikett ist die Schnittstelle. Der Roboter sieht das Etikett, erkennt eine passende Aufgabe und entscheidet sich, die Tasche zu öffnen.

In der Tasche werfen Sie nicht einfach einen unordentlichen Haufen Notizen hinein. Sie haben ein klares, schrittweises Rezept (den Body) und vielleicht noch ein paar zusätzliche Werkzeuge, wie zum Beispiel ein Skript, das automatisch die Änderungen zählt, oder einen Styleguide dafür, wie die Release Notes aussehen sollen. Dies ist die Implementierung. Das Papier nennt dies einen „Skill“ und besteht darauf, dass dieses gesamte Kit ein Software-Artefakt ist. Das ist ein schicker Begriff dafür, dass es sich um ein Stück Technologie handelt, das genauso gebaut, getestet und gepflegt werden muss wie ein Videospiel oder eine Website.

Der Autor argumentiert, dass ein Skill scheitern wird, wenn man ihn wie eine lockere Notiz behandelt. Wenn man ihn wie eine Software behandelt, wird er funktionieren. Hier ist die Aufschlüsselung der Regeln für den Bau dieser digitalen Kits, wie sie im Papier beschrieben werden:

1. Die Regel der „Einzigen Verantwortlichkeit“ (Single Responsibility)

Denken Sie an ein Schweizer Taschenmesser. Wenn Sie versuchen, ein Werkzeug zu bauen, das gleichzeitig Schraubendreher, Dosenöffner, Säge, Zahnbürste und Pizzaschneider ist, wird es in allem schlecht sein. Das Papier besagt, dass ein Skill eine Sache richtig gut machen sollte. Wenn ein Skill versucht, „alles rund um das Thema Coding“ zu machen, könnte der Roboter verwirrt werden, wann er ihn benutzen soll. Aber wenn der Skill spezifisch „Entwurf von Release Notes aus Pull Requests“ lautet, weiß der Roboter genau, wann er nach dem Greifen muss. Das Papier legt nahe, dass ein fokussierter Skill zuverlässiger von der KI ausgewählt wird.

2. Der Trick des „Gestuften Ladens“ (Staged Loading)

Stellen Sie sich vor, Sie haben eine Bibliothek mit einer Million Büchern. Wenn Sie versuchen würden, alle auf einmal zu lesen, um das eine zu finden, das Sie brauchen, würde Ihr Gehirn explodieren. Das Papier erklärt, dass KI-Skills einen cleveren Trick namens gestuftes Laden verwenden.

• Level 1 (Das Label): Zuer Sieht der Roboter nur das Etikett auf der Tasche (den Namen und eine kurze Beschreibung). Dies kostet sehr wenig „Gehirnschmalz“ (Tokens).
• Level 2 (Das Rezept): Wenn der Roboter glaubt, dass die Aufgabe zum Label passt, öffnet er die Tasche und liest das Hauptrezept.
• Level 3 (Die Werkzeuge): Er zieht die zusätzlichen Werkzeuge (Skripte oder Referenzdateien) erst heraus, wenn das Rezept explizit sagt: „Oh, ich brauche jetzt diese spezifische Datei.“

Das bedeutet, dass Sie einen Skill mit einer riesigen Bibliothek an Referenzmaterial in ihm haben können, und der Roboter wird nicht überfordert sein, es sei denn, er benötigt dieses Material tatsächlich. Es ist wie ein massiver Werkzeugkasten, bei dem man nur die Schublade öffnet, die man gerade braucht.

3. Die „Beschreibung“ ist der Auslöser

Der wichtigste Teil eines Skills ist die Beschreibung auf dem Etikett. Das Papier warnt davor, dass ein vages Label wie „Handhabt Releases“ dazu führt, dass der Roboter nicht weiß, wann er ihn nutzen soll. Es muss spezifisch sein: „Erstellt Release Notes aus den Pull Requests, die zwischen zwei Version-Tags gemerged wurden. Verwenden, wenn ein Release erstellt wird.“ Der Roboter gleicht die Aufgabe mit dieser Beschreibung ab. Wenn die Beschreibung unpräzise ist, könnte der Roboter den Skill ganz übersehen oder den falschen auswählen. Das Papier legt nahe, dass die Beschreibung der „Vertrag“ zwischen Ihnen und dem Roboter ist.

4. Testen mit „Verhaltensbewertung“ (Behavioral Evaluation)

In der normalen Programmierung kann man eine Funktion testen, indem man sie ausführt und prüft, ob das Ergebnis exakt „5“ ist. Aber KI ist anders. Der Roboter kann Ihnen jedes Mal eine etwas andere Antwort geben, selbst wenn er das Richtige tut. Das Papier sagt, dass man einen Skill nicht mit einer einfachen „Bestanden/Nicht bestanden“-Prüfung testen kann. Stattdessen muss man eine Verhaltensbewertung durchführen. Das bedeutet, man gibt dem Skill eine Reihe von realen Aufgaben, führt ihn viele Male aus und sieht nach, ob er die Aufgabe meistens korrekt erledigt. Es ist, als würde man ein neues Rezept testen, indem man es zehnmal kocht und probiert, anstatt nur zu prüfen, ob die Zutaten auf der Liste stehen.

Die große Verwirrung: Skills vs. andere Werkzeuge

Einer der größten Beiträge des Papers ist die Klärung der Verwirrung zwischen verschiedenen Wegen, einer KI zu sagen, was sie tun soll. Der Autor vergleicht Skills mit anderen Werkzeugen wie Hooks, Slash Commands und Memory Files.

Stellen Sie sich vor, Sie regissieren ein Theaterstück.

• Memory Files sind wie ein Skript, das immer auf der Bühne präsent ist, für die Schauspieler (die KI) in jedem einzelnen Moment der Aufführung sichtbar. Sie liefern den ständigen Projektkontext, der niemals verblasst, und stellen sicher, dass der Roboter diese Informationen jederzeit zur Verfügung hat, obwohl sie keine spezifische Aktion erzwingen.
• Slash Commands sind wie ein Bühnenarbeiter, der ruft: „Hey, mach jetzt den Zaubertrick!“ Sie (der Nutzer) müssen den Befehl geben. Der Roboter wartet auf Sie.
• Hooks sind wie ein strenger, automatisierter Sicherheitsmechanismus. Wenn der Schauspieler versucht, ohne Sicherung von der Bühne zu springen, führt der Sicherheitsmechanismus deterministisch eine Regel aus, um ihn aufzufangen oder die Aktion zu stoppen. Der Roboter kann dies nicht ignorieren; es passiert jedes Mal, wenn das spezifische Ereignis eintritt, unabhängig davon, was der Roboter entscheidet.
• Skills sind wie ein spezialisiertes prozedurales Werkzeugset, das bei Bedarf geladen wird. Wenn der Roboter auf eine Aufgabe stößt, gleicht er die Beschreibung ab und lädt die spezifischen Anweisungen, um diesen Bereich zu bearbeiten. Er ist eine Quelle von Expertenwissen, die der Roboter aktiv abruft, um ein Problem zu lösen, anstatt nur ein passiver Vorschlag zu sein.

Das Papier zieht eine klare Linie: Wenn etwas jedes einzelne Mal passieren muss (wie eine Sicherheitsprüfung vor dem Speichern einer Datei), müssen Sie einen Hook verwenden. Wenn Sie möchten, dass der Roboter sein Gehirn benutzt, um zu entscheiden, ob ein spezifisches Verfahren nötig ist, verwenden Sie einen Skill. Das Papier warnt davor, dass das Vermischen dieser Begriffe ein häufiger Fehler ist. Wenn Sie eine Sicherheitsregel innerhalb eines Skills schreiben, könnte der Roboter entscheiden, sie zu überspringen. Wenn Sie einen flexiblen Vorschlag innerhalb eines Hooks schreiben, könnte der Roboter dazu neigen, immer wieder dasselbe zu tun, selbst wenn er es nicht sollte.

Das „Vertrauensproblem“

Schließlich berührt das Papier ein beängstigendes, aber wichtiges Thema: Vertrauen. Wenn Sie einen Skill von jemand anderem (einem Drittanbieter) herunterladen, lassen Sie zu, dass dieser Anweisungen schreibt, denen Ihr Roboter folgen wird. Dieser Skill könnte Skripte enthalten, die Dateien löschen oder Daten ins Internet senden. Das Papier argumentiert, dass Sie einen Skill genau wie eine Software behandeln sollten, die Sie aus dem Internet herunterladen. Sie sollten nicht einfach nur auf „Installieren“ klicken. Sie müssen den Code lesen, die Skripte prüfen und sicherstellen, dass er sicher ist. Der Roboter wird genau das tun, was der Skill ihm sagt, also müssen Sie der Torwächter sein.

Das Fazleit

Das Papier von Giuseppe Destefanis ist ein Aufruf an alle, die KI-Tools entwickeln. Es sagt: „Hören Sie auf, KI-Anweisungen wie lockere Notizen zu behandeln. Beginnen Sie, sie wie ernsthafte Software zu behandeln.“

Indem wir die Prinzipien des Software Engineerings anwenden – die Dinge einfach zu halten, das Label vom Inhalt zu trennen, mit realen Szenarien zu testen und genau zu wissen, wann man einen Skill gegenüber einem Hook verwendet –, können wir KI-Agenten bauen, die nicht nur intelligent, sondern auch zuverlässig und sicher sind. Das Papier verspricht nicht, dass dies alle KI-Probleme lösen wird, aber es legt nahe, dass wir, wenn wir unsere Skills mit derselben Sorgfalt bauen wie unsere Apps, unsere digitalen Assistenten zu viel vertrauenswürdigeren Partnern machen können. Es geht darum, von „der Hoffnung, dass der Roboter es richtig macht“ zu „dem Engineering des Roboters, damit er es richtig macht“, überzugehen.