Skills entwickeln

Wiederverwendbare Pi-Agent Skills entwickeln

0:00 Es gibt in jedem Team dieses Wissen, das nur in Köpfen existiert: Wie man ein Release vorbereitet, wie man eine Migration schreibt, worauf man beim neuen Modul achten muss. Man erklärt es beim dritten Mal genauso mühsam wie beim ersten. Ein Skill ist genau die Anleitung, die Sie sonst jedes Mal neu erklären — nur dass sie diesmal aufgeschrieben ist und der Agent sie bei Bedarf selbst lädt.

0:21 In diesem Modul lernen Sie, wann sich das lohnt, wie so eine Anleitung aufgebaut ist und warum eine einzige Zeile darin über alles entscheidet.

Wissen wiederverwendbar machen

0:30 Acht Kapitel. Und ein technisches Detail vorweg, das den ganzen Ansatz erst sinnvoll macht: Skills werden bei Bedarf geladen, nicht dauerhaft mitgeschickt. Das ist der Unterschied zu den Projektanweisungen aus Modul sechs, die jeder Aufruf bezahlt. Ein Skill kostet nur dann Kontext, wenn er zur Aufgabe passt. Damit können Sie beliebig viel Wissen ablegen, ohne jeden Aufruf zu belasten — und genau deshalb ist es sinnvoll, Regeln und Abläufe zu trennen.

0:57 Vier Punkte. Erstens der Aufbau: eine Anleitungsdatei plus optionale Skripte und Nachschlagewerke. Zweitens das Ladeverfahren — Pi liest beim Start nur Namen und Beschreibungen und holt den Rest erst bei Bedarf; die Fachleute nennen das progressive Offenlegung. Drittens die Fundorte: global, projektlokal, im Paket. Und viertens die Frage, wie aus einzelnen Skills eine Bibliothek wird, die man tatsächlich benutzt — statt eines Ordners mit guten Absichten.

Vom einmaligen Prompt zum wiederverwendbaren Skill

1:26 Beginnen wir mit der Schwelle. Sie ist erfreulich niedrig: Eine einzige Markdown-Datei genügt, um aus einem Prompt eine dauerhafte Fähigkeit zu machen. Die Dokumentation nennt einen Skill ein in sich geschlossenes Fähigkeitspaket, das der Agent bei Bedarf lädt: eine Anleitungsdatei mit Kopfdaten und Text, dazu optional Skripte, Referenzen und Beispieldateien.

1:48 Verpflichtend ist nur die Anleitungsdatei. Das Bild: das laminierte Blatt an der Maschine, auf dem der Einrichtvorgang steht. Es ist nicht das Handbuch und nicht die Norm — es ist die Handreichung für genau diesen Vorgang. Und wer sie liest, macht es wie alle anderen. Ein Prompt wirkt einmal, ein Skill jedes Mal — das ist der ganze Unterschied.

2:08 Der Ablauf steht als Text und ist damit prüfbar, versionierbar und teilbar; er verlässt den Kopf und wird zum Projektbestandteil. Skripte im Skill machen mechanische Schritte deterministisch, was gerade bei Migrationen viel wert ist. Und noch einmal der Kontextvorteil: Geladen wird nur, wenn die Aufgabe passt. Ihre Sitzung bleibt schlank, obwohl Ihre Bibliothek wächst.

2:31 Worauf es hier ankommt, ist die Aufteilung, nicht die Ordnernamen. Die Anleitungsdatei ist Pflicht und enthält den Ablauf. Die Skripte nehmen die mechanischen Teile auf — alles, was nicht interpretiert werden soll. Die Referenzen enthalten die Details, die man nur manchmal braucht; sie werden nur gelesen, wenn sie gebraucht werden. Und in den Beispieldateien liegen Vorlagen.

2:54 Die Fußnote ist mir wichtig: Alles außer der Anleitungsdatei ist optional. Fangen Sie mit einer Datei an. Struktur können Sie hinzufügen, wenn der Skill wächst.

Geeignete Aufgaben für Skills identifizieren

3:04 Bevor wir schreiben, klären wir die Auswahl. Nicht jeder Ablauf verdient einen Skill — und ein Ordner voller ungenutzter Skills ist schlimmer als keiner, weil er Ladeentscheidungen verwässert. Drei Kriterien: Die Aufgabe kehrt wieder, sie hat mehrere Schritte, und ihr Ablauf lässt sich aufschreiben. Typische Kandidaten sind Release-Checks, Migrationsschritte, Analysen nach festem Muster oder Codegenerierung nach Projektkonvention. Alle drei Kriterien müssen zutreffen.

3:32 Eine einmalige Aufgabe lohnt den Aufwand nicht. Eine Ein-Schritt-Aufgabe passt besser in eine Prompt-Vorlage. Und was Sie nicht aufschreiben können, wird auch als Skill unzuverlässig — der Agent kann keine Lücke füllen, die Sie selbst nicht kennen. Vier Abgrenzungen. Einmalige Aufgaben: nicht lohnend. Ein-Schritt-Aufgaben: besser als Prompt-Vorlage, dazu kommt das nächste Modul.

3:55 Nicht beschreibbare Abläufe: bleiben unzuverlässig, egal in welcher Form. Und dauerhafte Regeln gehören weiterhin in die Projektanweisungen aus Modul sechs — nicht in einen Skill, weil Regeln immer gelten und nicht situativ geladen werden sollen. Diese vier Abgrenzungen ersparen Ihnen die Hälfte der Skills, die man im ersten Enthusiasmus anlegt.

4:18 Die Logik dieser Tabelle ist eine Entscheidungshilfe in vier Zeilen. Gilt es für jede Änderung? Dann Projektanweisungen. Ist es eine Formulierung mit einem Schritt? Dann Prompt-Vorlage. Ist es ein Ablauf mit mehreren Schritten? Dann Skill. Braucht es ein neues Werkzeug? Dann Erweiterung — und damit Code. Diese vier Fragen in dieser Reihenfolge, und Sie landen fast immer richtig. Die Fußnote gibt die Entwarnung dazu: Bei Zweifel klein anfangen.

4:47 Ein Skill lässt sich später aufteilen, das ist kein Drama. In dieser Übung bewerten Sie drei Kandidaten nach Häufigkeit, Schrittigkeit und Beschreibbarkeit — und wählen genau einen aus. Die Ablehnung der anderen beiden begründen Sie mit je einem Satz. Diese Ablehnung ist wieder der Lernkern, wie schon bei den Packages: Sie üben, den Aufwand gegen den Nutzen zu stellen, statt jede Idee umzusetzen.

5:11 Und der ausgewählte Kandidat begleitet Sie durch die nächsten Kapitel — Sie werden ihn nämlich gleich tatsächlich schreiben.

Skills strukturiert beschreiben

5:18 Jetzt kommt das wichtigste Kapitel dieses Moduls. Es geht um die Kopfdaten — und insbesondere um eine Zeile, die darüber entscheidet, ob Ihr Skill jemals zum Einsatz kommt. Die Kopfdaten verlangen zwei Angaben: einen Namen — kleine Buchstaben, Ziffern, Bindestriche, bis 64 Zeichen — und eine Beschreibung von bis zu 1024 Zeichen.

5:39 Und jetzt der entscheidende Satz: Die Beschreibung bestimmt, wann der Agent den Skill lädt. Optional gibt es weitere Felder, etwa eine Vorabfreigabe von Werkzeugen und einen Schalter, der den Skill aus dem Systemprompt heraushält. Aber alles hängt an der Beschreibung. Sie ist nicht der Titel, sie ist der Auslöser. Beim Start liest Pi nur Namen und Beschreibungen ein — nicht den ganzen Skill. Das ist die progressive Offenlegung, von der ich sprach.

6:07 Erst wenn eine Aufgabe passt, lädt der Agent die vollständige Anleitung. Daraus folgt unmittelbar: Eine vage Beschreibung führt dazu, dass der Skill nie greift, egal wie gut der Inhalt ist. Und es gibt einen ausdrücklichen Aufruf über einen Skill-Befehl, bei dem Argumente angehängt werden — der Weg, wenn Sie den Skill bewusst erzwingen wollen.

6:28 Worauf es hier ankommt, ist die zweite Hälfte der Beschreibung. Der erste Teil sagt, was der Skill tut. Der zweite Teil nennt Auslösewörter — die Formulierungen, mit denen Sie im Alltag tatsächlich sprechen: „Release", „Version anheben", „Changelog prüfen". Genau das macht den Unterschied zwischen einem Skill, der geladen wird, und einem, der im Ordner liegt. Denken Sie an Suchbegriffe für Ihr zukünftiges Ich.

6:53 Und schreiben Sie die Wörter hin, die Sie wirklich benutzen, nicht die, die im Handbuch stehen. Vier Fehler bei den Kopfdaten. Die Beschreibung wie einen Titel formulieren — „Release-Skill" enthält kein einziges Auslösewort. Den Ablauf in die Beschreibung packen statt in den Text; die Beschreibung ist Werbung, nicht Inhalt.

7:13 Namen mit Großbuchstaben oder Leerzeichen wählen, was schlicht nicht erlaubt ist. Und zwei Skills mit überlappender Beschreibung anlegen — dann entscheidet der Zufall, welcher geladen wird, und Sie wundern sich über wechselndes Verhalten. Alle vier sind in einer Minute behoben, wenn man sie kennt.

Entwicklungswissen wiederverwendbar machen

7:31 Jetzt zum Inhalt. Und hier trennt sich brauchbares Wissen von Befehlslisten: Ein guter Skill erklärt nicht nur die Schritte, sondern warum sie in dieser Reihenfolge stehen. Wiederverwendbar wird Wissen, wenn der Skill Ablauf, Reihenfolge und Begründung nennt — und Details in den Referenzordner auslagert, damit die Anleitung knapp bleibt.

7:51 Der Unterschied ist wichtig: Eine reine Befehlsliste kann der Agent nur nachplappern. Mit Begründungen kann er sinnvoll abweichen, wenn die Lage anders ist. Das ist wie bei einer Einarbeitung: Wer nur die Handgriffe lernt, steht beim ersten Sonderfall ratlos da. Wer den Zweck kennt, findet eine Lösung. Begründungen erlauben sinnvolle Abweichungen — der wichtigste Punkt.

8:13 Der Referenzordner wird nur gelesen, wenn er gebraucht wird; Sie können also ausführlich sein, ohne die Anleitung zu überladen. Skripte machen kritische Schritte reproduzierbar: Was ein Skript erledigt, macht das Modell nicht kreativ. Und Beispiele zeigen das Zielergebnis, was oft mehr erklärt als jede Beschreibung. Diese Aufteilung — kurze Anleitung, tiefe Referenz, harte Skripte — ist der Grund, warum Skills auch für komplexe Abläufe tragen.

8:40 Der rote Faden: mitschreiben, kürzen, prüfbar machen, aufteilen, auffindbar machen. Zuerst führen Sie den Ablauf einmal aus und schreiben mit — nicht aus dem Gedächtnis rekonstruieren, das lässt genau die Handgriffe weg, die man automatisch macht. Dann kürzen und die Reihenfolge festlegen. Dann je Schritt einen Nachweis ergänzen: „grün ist, wenn …". Dann Details und Mechanik auslagern.

9:05 Und zum Schluss die Beschreibung mit Auslösewörtern. Der Maßstab für Fertigsein: Eine fremde Person könnte dem Skill folgen.

Projektworkflows als Skills modellieren

9:13 Jetzt der häufigste Einsatzfall im Team: die Abläufe, die Ihr Projekt ohnehin hat. Sie sind der naheliegendste Kandidat, weil sie oft schon halb dokumentiert sind — in Wikis, die niemand liest. Projektworkflows sind mehrstufige Abläufe mit festen Regeln: ein neues Modul anlegen, eine Migration schreiben, ein Release vorbereiten, eine Abhängigkeit aktualisieren.

9:35 Als Skill modelliert laufen sie unabhängig davon, wer sie anstößt. Das ist der eigentliche Gewinn für ein Team: Der Ablauf hängt nicht mehr daran, ob die Person, die ihn kennt, gerade im Urlaub ist. Und weil der Skill im Repository liegt, wird er wie Code gepflegt und diskutiert. Gleiches Ergebnis, unabhängig von der Person am Terminal — das ist der Kern.

9:57 Projektlokale Skills liegen im Konfigurationsordner des Projekts und greifen nach vergebenem Projektvertrauen; der Mechanismus aus Modul drei arbeitet wieder für Sie. Über ein Paket lassen sich Skills teamweit oder projektübergreifend verteilen. Und ein angenehmer Nebeneffekt: Der Skill dokumentiert den Workflow gleich mit.

10:16 Sie schreiben keine zweite Dokumentation — die Anleitung für den Agenten ist die Dokumentation. Das Prinzip dieser drei Beispiele steckt in der Spalte „Auslöser". Achten Sie darauf, wie die Auslöser formuliert sind: „neues Modul anlegen", „Migration schreiben", „Release vorbereiten". Das sind Sätze aus dem Alltag, keine Kunstbegriffe.

10:36 Genau so gehören sie in die Beschreibung. Und die rechte Spalte nennt jeweils ein konkretes Ergebnis — Ordner samt Test und Registrierung, eine Migration samt Rückweg, eine abgearbeitete Prüfliste. Wenn Sie das Ergebnis nicht benennen können, ist der Skill noch nicht scharf genug geschnitten.

Skills für Analyse, Entwicklung und Qualitätssicherung einsetzen

10:54 Jetzt eine Einteilung nach Einsatzfeld — und damit auch nach Risiko. Diese Unterscheidung hilft besonders beim Einstieg, weil ein Feld praktisch risikofrei ist. Drei Felder: Analyse-Skills arbeiten lesend, Entwicklungs-Skills verändern Code nach Konvention, Prüf-Skills bewerten Ergebnisse. Und es gibt ein Feld in den Kopfdaten, mit dem ein Skill die dafür nötigen Werkzeuge vorab freigeben kann.

11:18 Das ist eine elegante Verbindung zum Sicherheitsmodul: Der Skill sagt selbst, was er braucht — und was er nicht braucht. Wer einen Analyse-Skill schreibt, kann ihn damit ausdrücklich auf lesende Werkzeuge beschränken. Analyse-Skills sind risikofrei und deshalb der beste Einstieg — Sie können nichts kaputt machen und sehen sofort, ob das Ladeverhalten funktioniert.

11:39 Entwicklungs-Skills brauchen klare Konventionen aus den Projektanweisungen; ohne sie erzeugen sie Code, der überall anders aussieht. Prüf-Skills liefern das Abnahmekriterium gleich mit, was die Kopplung zu Modul vier schließt. Und es gibt einen Schalter, der einen Skill aus dem Systemprompt heraushält — für Skills, die nur auf ausdrücklichen Aufruf laufen sollen.

12:00 Jetzt schreiben Sie Ihren ersten Skill — bewusst einen lesenden. Die Kriterien sind scharf: gültige Kopfdaten, Ablage im Projekt, wird bei passender Formulierung geladen, liefert eine Analyse ohne Dateiänderung. Achten Sie besonders auf das dritte Kriterium; das ist der Test Ihrer Beschreibung. Und wer mag, nimmt die Stretch-Variante und begrenzt die Werkzeuge in den Kopfdaten auf lesende.

12:23 Damit haben Sie einen Skill, den Sie auch in einem fremden Repository guten Gewissens laufen lassen können.

Persönliche und projektspezifische Fähigkeiten unterscheiden

12:30 Jetzt die Frage, wo ein Skill eigentlich liegen soll. Pi kennt mehrere Fundorte, und die Zuordnung ist im Alltag die häufigste Prüffrage — meist dann, wenn ein Skill nicht geladen wird. Pi sucht global in zwei Verzeichnissen des Benutzers und projektlokal in zwei Verzeichnissen des Projekts — letztere erst nach Projektvertrauen, und auch in übergeordneten Verzeichnissen.

12:53 Dazu kommen Pakete, eine Liste in den Einstellungen und eine Startoption für einen einzelnen Skill-Pfad. Das klingt nach viel, folgt aber einer klaren Logik: von persönlich über projektbezogen bis geteilt. Wenn Sie sich nur eine Zuordnung merken: Persönliches global, Projektwissen ins Repository. Persönliche Arbeitsweise gehört global — sie hat im Team-Repository nichts zu suchen, weil sie dort im Review nur Rauschen erzeugt.

13:18 Projektwissen gehört ins Projekt, damit es alle bekommen. Zwei technische Details, die im Alltag helfen: Verzeichnisse werden rekursiv nach Anleitungsdateien durchsucht, Sie können also Unterordner bilden. Und einzelne Markdown-Dateien gelten als Skill, wenn ihre Kopfdaten samt Beschreibung stimmen — für einfache Fälle braucht es also nicht einmal einen Ordner.

13:40 Der rote Faden sind drei Fragen und zwei Handgriffe. Gilt das nur für mich? Global. Braucht das Team es auch? Ins Projekt. Sollen mehrere Projekte es teilen? Paket. Dann legen Sie den Skill am gewählten Ort an und starten neu oder laden neu. Und der fünfte Schritt ist der, der Ihnen Ärger erspart: mit einer echten Formulierung testen, ob er geladen wird.

14:02 Die Fußnote fasst meine Erfahrung zusammen: Wird ein Skill nie geladen, liegt es fast immer an der Beschreibung — nicht am Ort.

Eine eigene Skill Bibliothek aufbauen

14:11 Zum Abschluss der Blick auf die Sammlung. Eine Bibliothek ist mehr als ein Ordner voller Dateien — sie braucht Trennschärfe und Pflege, sonst arbeitet sie gegen Sie. Eine Skill-Bibliothek ist eine überschaubare Sammlung benannter, getesteter Skills mit klaren Auslösern und ohne Überlappung — global das Persönliche, im Repository das Projektbezogene, im Paket das Geteilte.

14:33 Die entscheidenden Wörter sind „getestet" und „ohne Überlappung". Der Vergleich: ein Regal mit beschrifteten Kisten. Wenn zwei Kisten dasselbe Etikett haben, greifen Sie irgendwann in die falsche — und bei einem Agenten passiert genau das, nur dass Sie es nicht bemerken. Wenige gute Skills werden benutzt, viele mittelmäßige nicht — das ist die nüchterne Beobachtung.

14:56 Überlappende Beschreibungen führen zu falschen Ladeentscheidungen; das ist der technische Grund, warum Aufräumen hier kein Ordnungsfetisch ist. Regelmäßiges Aufräumen hält die Auswahl trennscharf. Und jeder Skill braucht einen erprobten Auslösesatz — notieren Sie ihn am besten im Skill selbst. Dann können Sie in sechs Monaten prüfen, ob er noch funktioniert, ohne raten zu müssen.

15:19 Vier typische Fehlentwicklungen. Skills anlegen „für später", ohne echten Anlass — das erzeugt Überlappung ohne Nutzen. Ablauf und Regeln vermischen; Regeln gehören in die Projektanweisungen, das ist die Trennung aus Modul sechs. Skills nie testen und sich dann über Nichtladen wundern — der häufigste Frustpunkt. Und alte Skills behalten, obwohl der Workflow sich geändert hat; dann folgt der Agent gewissenhaft einem Ablauf, den Ihr Team längst verlassen hat.

15:46 Das ist schlimmer als kein Skill.

Wissen, das mitarbeitet

15:49 Drei Sätze zum Mitnehmen. Ein Skill ist eine Anleitungsdatei plus optional Skripte und Referenzen — die Schwelle ist eine Datei. Die Beschreibung entscheidet, ob er je zum Einsatz kommt; investieren Sie dort Ihre Sorgfalt. Und die Zuordnung ist einfach: global das Persönliche, im Repository das Projektwissen. Im nächsten Modul kommt der kleine Bruder des Skills — die Prompt-Vorlage.

16:12 Sie ist reiner Text, in zwei Minuten geschrieben und für die vielen kleinen Formulierungen genau das richtige Werkzeug.