Agent Skills und wiederverwendbare Fähigkeiten

Agent Skills und wiederverwendbare Fähigkeiten

0:00 In jedem Team gibt es Abläufe, die jeder etwas anders macht. Ein Endpunkt anlegen, ein Release vorbereiten, eine Prüfliste abarbeiten. Meist sind sie nirgends beschrieben — man lernt sie durch Zusehen. In diesem Modul geht es darum, solche Abläufe zu verpacken: als Skill, den der Agent lädt, wenn er passt. Das klingt zunächst nach Dokumentation, ist aber etwas anderes. Ein Skill wird nicht gelesen, sondern ausgeführt.

0:26 Und damit wird aus einer persönlichen Gewohnheit eine Fähigkeit, die dem ganzen Team zur Verfügung steht.

Agent Skills und wiederverwendbare Fähigkeiten

0:33 Der Leitsatz: Was Sie dreimal erklärt haben, sollte beim vierten Mal ein Werkzeug sein. Acht Kapitel führen von der Frage, was ein Skill überhaupt leistet, über den konkreten Aufbau bis zu der Abgrenzung, die am häufigsten falsch gemacht wird — der zwischen Skills und Projektregeln. Am Ende steht der Weg vom gelungenen Prompt zum geteilten Engineering-Prozess. Beispielprojekt bleibt kanuverleih, jetzt mit eigenen wiederverwendbaren Abläufen.

Was Skills im Engineering leisten

0:59 Beginnen wir mit der Einordnung. Sie kennen inzwischen zwei Wege, Verhalten festzulegen: den Prompt für den Einzelfall und die Projektregeln für das Dauerhafte. Skills sind der dritte Weg, und er füllt eine Lücke, die man erst bemerkt, wenn man sie kennt. Sehen wir uns an, welche das ist und wann sich der Aufwand lohnt.

1:18 Ein Skill bündelt Anweisungen, Hilfsmittel und optionale Skripte zu einem benannten Ablauf, dem Codex zuverlässig folgen kann. Er liegt als Verzeichnis mit einer Datei namens SKILL.md vor und wird bei Bedarf geladen. Der letzte Teil ist das Entscheidende: bei Bedarf. Der Agent kennt zunächst nur Name und Beschreibung aller Skills. Erst wenn eine Beschreibung zur Aufgabe passt, lädt er die vollständigen Anweisungen.

1:44 Deshalb dürfen Skills ausführlich sein, ohne dass sie ständig Platz kosten. Vier Gewinne. Der Ablauf ist geschrieben statt jedes Mal erinnert — und was geschrieben steht, wird nicht bei Zeitdruck abgekürzt. Er läuft bei allen im Team gleich ab, unabhängig davon, wer gerade arbeitet. Er ist versioniert und im Review verbesserbar wie Code.

2:04 Und er kann Skripte enthalten, wo Genauigkeit zählt. Der letzte Punkt ist ein Unterschied zur reinen Dokumentation: Ein Skill kann Teile seines Ablaufs deterministisch ausführen, statt sie zu beschreiben und zu hoffen. Diese Tabelle ordnet die drei Mittel nach ihrer Reichweite. Der Prompt gilt einmalig für diese eine Aufgabe. Die Projektregeln gelten immer, für Regeln und Konventionen.

2:28 Und der Skill gilt bei Bedarf, für einen benannten Ablauf. Die Fußzeile beschreibt den Unterschied, der im Alltag zählt: Skills werden geladen, wenn sie passen — Regeln gelten unabhängig davon immer. Daraus folgt eine klare Zuordnung, auf die wir in Kapitel sieben zurückkommen: Was auch dann gelten muss, wenn niemand den Skill ruft, gehört in die Regeln.

2:49 Der erste Punkt betrifft die Verhältnismäßigkeit: Ein Skill für etwas, das man einmal braucht, lohnt nicht. Der zweite ist eine Abgrenzung — Skills ersetzen keine Projektregeln, sie ergänzen sie. Der dritte beschreibt ein Problem, das mit wachsender Sammlung auftritt: Zu viele Skills konkurrieren um dieselbe Aufgabe, und der Agent wählt möglicherweise den falschen.

3:10 Und der vierte fasst zusammen, was gleich noch ausführlich kommt: Ein Skill ohne klare Abgrenzung wird nie oder immer geladen — beides ist unbrauchbar.

Aufgaben standardisieren

3:20 Bevor man einen Skill baut, sollte man wissen, wofür. Und die Antwort darauf findet man nicht durch Nachdenken, sondern durch Beobachten — ähnlich wie bei den Projektregeln in Modul drei. Sehen wir uns an, welche Abläufe sich eignen, woran man sie erkennt und warum ein Schritt dabei unverzichtbar ist, den viele überspringen.

3:39 Kandidaten für einen Skill sind Abläufe mit fester Reihenfolge, die mehrfach vorkommen und deren Ergebnis prüfbar ist — etwa ein Release vorbereiten, einen Endpunkt anlegen oder eine Prüfliste abarbeiten. Drei Merkmale also: feste Reihenfolge, Wiederholung, prüfbares Ergebnis. Fehlt eines davon, ist ein Skill das falsche Mittel.

3:58 Ein Ablauf ohne feste Reihenfolge lässt sich nicht beschreiben. Einer ohne Wiederholung lohnt den Aufwand nicht. Und einer ohne prüfbares Ergebnis endet beliebig — dann wissen Sie nie, ob er funktioniert hat. Fünf Schritte, und der zweite ist der, den man gern überspringt. Wiederholte Abläufe notieren. Den Ablauf einmal selbst von Hand sauber durchführen.

4:20 Schritte, Eingaben und Ergebnis aufschreiben. Als Skill fassen und an einem echten Fall erproben. Und nach jedem Einsatz nachschärfen. Die Fußzeile begründet Schritt zwei: Was man selbst nicht sauber kann, kann man nicht beschreiben. Wer einen Ablauf standardisiert, den er selbst nur ungefähr beherrscht, standardisiert seine Unsicherheit — und verteilt sie ans ganze Team.

4:43 Vier Merkmale. Der Ablauf hat einen Anfang und ein prüfbares Ende. Die Schritte sind stabil, nur die Eingaben wechseln — das ist die Voraussetzung dafür, dass er sich überhaupt beschreiben lässt. Fehler in der Reihenfolge kosten spürbar Zeit; genau dort liegt der Gewinn. Und mehrere Personen führen ihn unterschiedlich aus.

5:03 Der letzte Punkt ist der beste Indikator überhaupt: Wo im Team drei Varianten existieren, gibt es keinen Konsens — und ein Skill zwingt Sie, einen herzustellen. Diese Übung ist Beobachtungsarbeit. Notieren Sie drei Kandidaten, jeweils mit Häufigkeit, Schritten und prüfbarem Ergebnis. Der Hinweis nennt die ergiebigste Suchrichtung: Achten Sie auf Abläufe, bei denen im Team jeder eine eigene Variante hat.

5:28 Solche Stellen erkennt man daran, dass in Reviews wiederkehrend dieselbe Diskussion aufkommt — nicht über den Code, sondern über das Vorgehen. Genau dort lohnt sich ein Skill doppelt: Er beschleunigt und er entscheidet.

Eigene Skills konzipieren

5:41 Jetzt wird es konkret. Ein Skill ist erstaunlich wenig: ein Verzeichnis, eine Datei, ein Kopf mit Name und Beschreibung. Aber eine dieser Angaben entscheidet über alles — nämlich darüber, ob der Skill überhaupt jemals geladen wird. Sehen wir uns den Aufbau an und warum die Beschreibung so viel Aufmerksamkeit verdient. Ein Skill ist ein Verzeichnis mit einer SKILL.md. Deren Kopf trägt Name und Beschreibung, und die Beschreibung entscheidet, wann der Skill überhaupt in Betracht kommt.

6:11 Darunter stehen die Anweisungen selbst. Diese Zweiteilung ist wichtig zu verstehen: Der Agent liest zunächst nur den Kopf. Er entscheidet anhand der Beschreibung, ob dieser Skill zur aktuellen Aufgabe passt. Was in den Anweisungen steht, sieht er zu diesem Zeitpunkt gar nicht. Eine gute Anleitung mit schlechter Beschreibung bleibt deshalb ungenutzt.

6:33 Ein Verzeichnis mit vier möglichen Bestandteilen. Die SKILL.md mit Name, Beschreibung und Anweisungen — sie ist als Einzige Pflicht. Dazu optional ein Ordner für Skripte, wenn es auf Genauigkeit ankommt; einer für Hintergrundwissen, das nicht in die Hauptdatei passt; und einer für Vorlagen. Die Fußzeile ist der praktische Rat: Fangen Sie mit der einen Datei an. Alles Weitere kommt hinzu, wenn Sie merken, dass es fehlt — nicht, weil die Struktur es vorsieht.

7:02 Ein Name und eine Beschreibung, mehr steht im Kopf nicht. Aber sehen Sie sich die Beschreibung genau an: Sie nennt nicht nur, wofür der Skill da ist, sondern auch, wofür nicht. „Nicht für Änderungen an bestehenden Endpunkten verwenden." Diese Abgrenzung ist der Teil, den die meisten weglassen — und genau der verhindert, dass ein Skill in Situationen greift, für die er nicht gedacht ist.

7:25 Zweck und Abgrenzung, beides. Denn der Agent hat nur diesen Text, um zu entscheiden. Der erste Punkt ist die direkte Folge des eben Gesagten: Eine vage Beschreibung führt zu zufälligem Laden. Der zweite ist die Kehrseite — ohne Abgrenzung verdrängt ein Skill die passenderen. Der dritte betrifft die Frage, wann man Skripte einsetzt: Wo Anweisungen genügen, machen Skripte den Skill spröde und schwerer anzupassen.

7:50 Und der vierte beschreibt das Ergebnis von zu viel Ehrgeiz: Ein Skill, der alles kann, wird für nichts geladen, weil seine Beschreibung auf alles und damit auf nichts passt.

Projektwissen einbinden

8:00 Kommen wir zu der Frage, was einen Skill eigentlich wertvoll macht. Es sind nicht die offensichtlichen Schritte — die kennt der Agent ohnehin. Es ist das, was nur in Ihrem Projekt gilt und was man ohne Erfahrung nicht wissen kann. Sehen wir uns an, wie man dieses Wissen greifbar macht. Der Wert eines Skills liegt im Nichtoffensichtlichen: in der Reihenfolge, die sich bewährt hat, in den Fallstricken dieses Projekts und in den Entscheidungen, die man sonst jedes Mal neu trifft.

8:28 Alles, was ein Agent sich selbst erschließen kann, gehört nicht hinein. Der Test ist einfach: Würde ein erfahrener Entwickler, der Ihr Projekt nicht kennt, diesen Schritt von allein machen? Wenn ja, streichen Sie ihn. Wenn nein, ist er genau der Grund, warum es diesen Skill gibt. Vier Inhalte. Die Reihenfolge, die Fehler vermeidet — oft hart erarbeitetes Wissen. Die Stellen, die erfahrungsgemäß vergessen werden.

8:53 Die projektübliche Entscheidung bei Wahlmöglichkeiten, damit nicht jedes Mal neu diskutiert wird. Und das Kriterium, an dem der Ablauf als fertig gilt. Der letzte Punkt fehlt in fast jedem ersten Entwurf. Ohne ihn endet der Skill dort, wo der Agent meint, genug getan zu haben — und das ist selten dieselbe Stelle, die Sie im Sinn hatten.

9:14 Fünf Schritte für unser Beispiel: einen Endpunkt anlegen. Route registrieren, Fachlogik ergänzen, Test anlegen — Fehlerfall zuerst —, die Schnittstellendatei nachziehen und am Ende Test und Linter grün bekommen. Die Fußzeile nennt den eigentlichen Grund für diesen Skill: Punkt vier. Die Schnittstellendokumentation nachzuziehen vergisst jeder einmal, weil sie außerhalb des Codes liegt und nichts kaputtgeht, wenn sie fehlt.

9:39 Genau solche Stellen rechtfertigen den Aufwand. Der erste Punkt betrifft die Verwässerung: Selbstverständlichkeiten aufzuschreiben verdünnt den Kern, und der Skill wird länger, ohne besser zu werden. Der zweite ist eine Abgrenzung — was schon in den Projektregeln steht, gehört nicht noch einmal hierher. Der dritte ist eine Erinnerung: Skills veralten wie Code und brauchen Pflege.

10:01 Und der vierte wiederholt die häufigste Lücke: Ein Skill ohne Abschlusskriterium endet beliebig, und dann ist er unzuverlässig statt hilfreich.

Fähigkeiten für Entwicklung und QS

10:09 Es gibt einen Bereich, in dem sich Skills besonders auszahlen, und das ist die Qualitätssicherung. Der Grund ist unangenehm ehrlich: Es sind die Abläufe, die immer gleich sind und genau deshalb unter Druck als Erstes leiden. Sehen wir uns an, welche typischen Skills sich dafür anbieten. Qualitätssicherung besteht aus Abläufen, die immer gleich sind und genau deshalb nachlassen: Prüflisten, Testarten, Abnahmeschritte.

10:34 Als Skill sind sie nicht mehr von Tagesform abhängig. Das ist der eigentliche Gewinn — nicht die Geschwindigkeit, sondern die Gleichmäßigkeit. Eine Prüfliste, die ein Mensch abarbeitet, wird beim zwanzigsten Mal kürzer als beim ersten. Ein Skill wird das nicht. Er ist um zweiundzwanzig Uhr vor dem Release genauso gründlich wie am ruhigen Dienstagvormittag.

10:56 Vier Beispiele mit ihrem jeweiligen Ergebnis. Einen Endpunkt anlegen — Route, Logik, Test, Doku. Eine Review-Prüfliste, die Befunde nach festen Kriterien liefert. Testlücken suchen und als Liste ausgeben. Und ein Release vorbereiten: Changelog, Version, Prüflauf. Die Fußzeile nennt das Auswahlkriterium, das am besten funktioniert: Je öfter ein Ablauf unter Zeitdruck stattfindet, desto mehr lohnt sein Skill.

11:23 Denn genau dann werden Schritte übersprungen — und genau dann fällt es niemandem auf. Der Hinweis zu dieser Übung ist entscheidend für ihren Erfolg: Wählen Sie einen Ablauf, den Sie diese Woche ohnehin brauchen. Ein Skill, der für eine Übung gebaut wird, bleibt Theorie und wird nie nachgeschärft. Einer, den Sie am selben Tag einsetzen, zeigt Ihnen sofort seine Schwächen.

11:46 Das Erfolgskriterium ist streng: Der Skill liefert dasselbe Ergebnis wie Ihre Handarbeit. Wenn nicht, fehlt genau das Stück Projektwissen, um das es in diesem Modul geht.

Skills projektübergreifend einsetzen

11:57 Skills können an verschiedenen Orten liegen, und der Ort bestimmt, wo sie wirken. Das klingt nach einem Detail für die Dokumentation, hat aber eine praktische Folge, die man kennen sollte — vor allem, wenn man eigene Gewohnheiten in fremde Projekte mitnimmt. Sehen wir uns die Ablagen an. Skills werden aus mehreren Ablagen geladen: aus dem Repository für projektbezogene Abläufe, aus dem Heimatverzeichnis für persönliche und aus systemweiten Ablagen für alle Nutzer einer Maschine.

12:26 Diese Staffelung kennen Sie inzwischen — sie entspricht der von Projektregeln. Und die Empfehlung ist dieselbe: Im Zweifel enger wählen. Ein Skill, der im Repository liegt, wird mitgereviewt und mit dem Projekt weiterentwickelt. Einer im Heimatverzeichnis gehört Ihnen allein. Drei Ablagen mit klarer Zuordnung. Das Repository für Abläufe dieses Projekts, im Team geteilt. Das Heimatverzeichnis für Ihre eigene Arbeitsweise über Projekte hinweg.

12:53 Und die systemweite Ablage für Vorgaben, die für alle Nutzer der Maschine gelten sollen. Die Fußzeile enthält die wichtigste Empfehlung: Projektbezogene Skills gehören ins Repository, denn nur dort werden sie mitgereviewt. Ein Skill, den niemand außer Ihnen sieht, altert unbemerkt — und niemand kann ihn verbessern. Vier Faustregeln. Hängt der Ablauf am Projektaufbau, gehört er ins Repository. Ist er Ihre persönliche Gewohnheit, gehört er nach Hause.

13:22 Gilt er für die ganze Organisation, kommt die systemweite Ablage in Frage. Und im Zweifel: enger wählen und später hochziehen. Der letzte Rat ist der praktischste. Einen Skill vom Repository ins Heimatverzeichnis zu heben ist ein Kopiervorgang. Ihn wieder einzufangen, nachdem er in fünf Projekten unbemerkt gewirkt hat, ist deutlich mühsamer.

13:44 Der erste Punkt ist der, der am ehesten überrascht: Persönliche Skills wirken unbemerkt auch in fremden Projekten — auch in denen Ihrer Kunden. Der zweite betrifft Namenskollisionen zwischen den Ablagen, die schwer zu durchschauen sind. Der dritte beschreibt eine typische Fehlerquelle: Ein Skill mit Projektannahmen versagt anderswo still — er läuft, aber er tut das Falsche.

14:06 Und der vierte erinnert daran, dass ein geteilter Skill ohne Review unbemerkt altert.

Skills und Projektregeln

14:11 Jetzt zu der Abgrenzung, die am häufigsten falsch gemacht wird. Skills und Projektregeln sehen sich ähnlich — beides ist Markdown im Repository, beides beeinflusst das Verhalten des Agenten. Aber sie lösen verschiedene Probleme, und sie zu verwechseln hat Konsequenzen. Sehen wir uns an, welche. Projektregeln und Skills lösen verschiedene Probleme. Die AGENTS.md legt fest, was in jeder Session gilt.

14:36 Ein Skill beschreibt einen Ablauf, der nur dann geladen wird, wenn seine Beschreibung zur Aufgabe passt. Daraus folgt der wichtigste Merksatz dieses Kapitels: Eine Regel, die Sie in einen Skill schreiben, gilt nur, wenn der Skill geladen wird. Wenn Ihre Sicherheitsregel im Release-Skill steht, greift sie bei jeder Arbeit, die nichts mit Releases zu tun hat, überhaupt nicht.

14:59 Drei Zeilen, die den Unterschied greifbar machen. Wann aktiv: die Regeln immer, der Skill nur wenn passend. Inhalt: dort Regeln und Befehle, hier ein Ablauf mit Schritten. Umfang: die Regeln knapp halten, der Skill darf ausführlich sein. Die Fußzeile erklärt, warum das letzte funktioniert: Weil Skills nur bei Bedarf geladen werden, belasten sie den Kontext nicht dauerhaft.

15:22 Ein ausführlicher Skill kostet Sie nichts, solange er nicht gebraucht wird. Eine ausführliche Regeldatei kostet Sie in jeder Session. Vier Gründe. Regeln im Skill greifen nur, wenn er geladen wird — der schon genannte Kernpunkt. Abläufe in den Projektregeln kosten in jeder Session Kontext, auch wenn sie selten gebraucht werden.

15:42 Beschreibungen entscheiden über das Laden, nicht der Inhalt; ein perfekter Skill mit schwacher Beschreibung bleibt liegen. Und doppelt gepflegte Aussagen laufen auseinander — nach ein paar Monaten stehen an zwei Stellen zwei verschiedene Wahrheiten. Der Hinweis liefert die Prüffrage, die alles entscheidet: Muss diese Aussage auch dann gelten, wenn niemand den Skill ruft?

16:04 Wenn ja, gehört sie in die Projektregeln, egal wie gut sie in den Skill passt. Wenn nein, ist der Skill der richtige Ort. Gehen Sie damit Ihre eigene Sammlung durch. Sie werden vermutlich mindestens eine Aussage finden, die an der falschen Stelle steht — und das ist keine Kleinigkeit, denn sie gilt dann eben nicht.

Vom Prompt zum Engineering-Prozess

16:23 Zum Abschluss der Weg, um den es in diesem Modul eigentlich geht: Aus einem gelungenen Prompt wird eine Gewohnheit, aus der Gewohnheit ein Skill und aus dem Skill ein Verfahren, das das Team trägt. Sehen wir uns an, wie diese Entwicklung abläuft und woran man erkennt, dass sie noch nicht abgeschlossen ist. Der Weg führt von einem gelungenen Prompt über den wiederholten Ablauf zum geteilten, versionierten Skill.

16:46 Am Ende steht kein Kniff Einzelner, sondern ein Verfahren, das im Repository steht und weiterentwickelt wird. Das ist die eigentliche Bedeutung dieses Themas. Denn produktive Einzelne gab es immer. Was ein Team stärker macht, ist, wenn deren Vorgehen für alle verfügbar wird — und Skills sind ein Format, in dem das erstmals ohne großen Aufwand gelingt.

17:07 Fünf Stufen. Den gelungenen Ablauf beim nächsten Mal wiederholen. Als Skill fassen und selbst benutzen. Im Team vorstellen und Rückmeldung einarbeiten. Ins Repository legen und mitreviewen. Und nach echten Einsätzen weiter nachschärfen. Die Fußzeile markiert die Grenze zwischen Werkzeug und Prozess: Ein Skill, den nur sein Autor benutzt, ist noch kein Prozess.

17:29 Erst wenn ihn jemand anderes einsetzt und dabei etwas findet, das Sie nicht bedacht haben, wird er robust. Der erste Punkt beschreibt eine verbreitete Form der Beschäftigungstherapie: Skills sammeln, ohne sie je einzusetzen. Der zweite betrifft den Zeitpunkt — einen Ablauf zu standardisieren, bevor er sich bewährt hat, zementiert eine Vermutung.

17:50 Der dritte ist die Pflege: Ein alter Skill führt aktiv in die Irre, so wie eine alte Regel. Und der vierte ist eine Grenze, die man respektieren sollte: Prozesse erzwingen, wo Ermessen nötig bleibt, macht die Arbeit schlechter, nicht besser. Diese Übung hat einen eingebauten Test, der nicht zu betrügen ist: Eine zweite Person führt den Ablauf allein mit Ihrem Skill durch.

18:12 Wenn sie zum gleichen Ergebnis kommt, ist der Skill vollständig. Wenn nicht, fehlt etwas — und der Hinweis sagt Ihnen, wo: Die Rückfragen dieser Person sind Ihre Verbesserungsliste. Notieren Sie jede einzelne. Es sind genau die Stellen, an denen Ihr Wissen stillschweigend eingeflossen ist, ohne aufgeschrieben zu werden. Vier Punkte zum Mitnehmen. Ein Skill verpackt einen Ablauf, während Projektregeln unabhängig davon immer gelten.

18:39 Die Beschreibung entscheidet, ob ein Skill überhaupt geladen wird — sie verdient mehr Sorgfalt als der Rest. Der Wert liegt im Nichtoffensichtlichen: Reihenfolge, Fallstricke, Abschlusskriterium. Und ein Skill wird erst zum Prozess, wenn andere ihn benutzen. Im nächsten Modul erweitern wir die Reichweite des Agenten über das Repository hinaus — mit MCP und externen Werkzeugen.