Agent Skills – Arbeit einmal beschreiben, immer wieder nutzen

Das Erklären, das nie aufhört

Montagmorgen. Du öffnest einen Chat und tippst zum vierzigsten Mal, wie der Wochenreport aussehen soll. Welche Zahlen zuerst. Welcher Ton. Was auf keinen Fall reingehört. Die KI liefert etwas Brauchbares, du korrigierst zweimal nach, das Ergebnis passt. Nächsten Montag fängst du von vorne an.

Das Ergebnis ist jedes Mal in Ordnung. Der Weg dorthin ist jedes Mal derselbe. Und genau das ist die Verschwendung: Du zahlst deine Einarbeitung wöchentlich neu, statt einmal.

Prompt, Projektanweisung, Skill

Drei Dinge, die oft in einen Topf geworfen werden. Sie unterscheiden sich darin, wie lange sie leben und wer den Ablauf im Kopf behält.

Die Projektanweisung sagt, wie hier generell gearbeitet wird. Der Skill sagt, wie diese eine Aufgabe abläuft. Dieselbe Disziplin, eine Ebene spezifischer. Wer schon mit einer Projekt-Anweisungsdatei gearbeitet hat, kennt das Prinzip aus Prompts, die halten.

Wo Skills in der Reifetreppe stehen

In der Lesson KI-Agenten führen stehen vier Stufen: erst der Assistent im Chat, dann Skills, dann automatisierte Abläufe, dann der Agent, der orchestriert. Skills sind Stufe zwei. Sie sind der Punkt, an dem du aufhörst, Muster zu wiederholen, und anfängst, sie festzuhalten. Diese Lesson füllt diese Stufe aus.

Geliehenes Werkzeug oder eigener Prozess

Skills teilen sich in zwei Familien. Der Unterschied ist nicht technisch, sondern eine Frage der Herkunft: Kann ich den fertig übernehmen, oder steckt mein eigener Ablauf drin?

Helfer-Skills sind ein guter Einstieg, weil du sofort siehst, wie sich ein Skill anfühlt. Der eigentliche Hebel liegt aber bei den Arbeits-Skills. Dort steckt das Wissen, das sonst nur in deinem Kopf liegt.

Arbeits-Skills: mit dir oder ohne dich

Arbeits-Skills teilen sich noch einmal. Die Frage ist, ob während des Ablaufs eine Entscheidung fällt, die dir gehört.

Der Lohnt-sich-Test

Nicht jede Aufgabe verdient einen Skill. Ein Skill kostet Aufbau und Pflege. Drei Fragen entscheiden.

1. Wiederholt sich die Aufgabe? Mindestens wöchentlich, in erkennbar gleicher Form. Einmal im Quartal lohnt sich nicht.
2. Gibt es einen richtigen Weg? Du kannst benennen, was ein gutes Ergebnis ausmacht. Wenn du es selbst nur ahnst, kann der Skill es nicht treffen.
3. Kannst du das Ergebnis prüfen? Du erkennst in unter einer Minute, ob der Output taugt. Ohne Prüfbarkeit baust du eine Blackbox.

Die Praktikanten-Regel

Ein neuer Praktikant übernimmt am ersten Tag nicht deinen Job. Er macht die Aufgabe, du siehst drüber, du korrigierst, beim dritten Mal sitzt es. Niemand käme auf die Idee, ihn nach dem ersten Versuch abzuschreiben.

Bei Skills passiert genau das. Der erste Lauf ist mittelmäßig, der Skill wandert in den Papierkorb, das Fazit lautet: funktioniert nicht. Dabei war der erste Lauf nie das Produkt. Er war die erste Runde Einarbeitung.

Der zweite Fehler: alles in einen Skill

Die Versuchung ist groß. Ein Skill, der recherchiert, daraus einen Artikel schreibt, Social-Posts ableitet und Bilder erzeugt. Ein Knopf, alles fertig. Das scheitert zuverlässig.

Der Grund ist Context Rot. Je länger ein Durchlauf wird und je mehr Rohmaterial sich ansammelt, desto schwächer wirken die Anweisungen vom Anfang. Am Ende schreibt der Agent Social-Posts, ohne sich noch an die Tonregeln aus Schritt eins zu erinnern. Warum das passiert, steht in Context Management und in Vom Prompt zum Loop.

Der Schnitt gehört dorthin, wo ein Zwischenergebnis steht, das du anschauen und freigeben kannst. Recherche fertig. Artikel fertig. Posts fertig. Die drei Skills rufst du nacheinander im selben Chat auf, das Ergebnis des einen ist das Material des nächsten.

Die Frage vor der Frage

Bevor du überlegst, was in der Datei steht, überleg, woher der Inhalt kommt. Es gibt vier Wege, und sie unterscheiden sich massiv in der Trefferquote.

Weg 1: Der Einzeiler

„Bau mir einen Skill, der meine Angebote prüft." Das Ergebnis sieht aus wie ein Skill und ist keiner. Es fehlt alles, was deinen Fall ausmacht: die Ausnahmen, die Prüfkriterien, der Ton, die Stellen, an denen du sonst nachfragst. Für einen Helfer-Skill mag das reichen. Für deinen Prozess nie.

Weg 2: Einmal gemeinsam machen

Der Goldstandard für alles, was du längst tust. Du machst die Aufgabe einmal zusammen mit dem Agenten, korrigierst unterwegs, und lässt am Ende den Skill aus dem Verlauf ableiten. Der Skill entsteht aus dem, was tatsächlich passiert ist, inklusive deiner Korrekturen.

Diese Bewegung kennst du, wenn du Reverse Engineering gemacht hast. Dort ziehst du aus einem fertigen Ergebnis die Vorlage. Hier ziehst du aus einem gelaufenen Prozess den Ablauf. Gleiche Richtung, eine Ebene höher.

Weg 3: Erst befragen lassen, dann bauen

Für Prozesse, die du noch nicht eingespielt hast. Neue Software, neues Produkt, neue Aufgabe. Hier gibt es keinen Durchlauf, den man mitschneiden könnte. Also drehst du es um: Der Agent fragt dich aus, bis der Ablauf steht, und baut erst danach.

Weg 4: Fremden Skill übernehmen

Schnell und legitim, aber nie das Ende. Ein übernommener Skill kennt deine Kriterien nicht, deine Ausnahmen nicht, deinen Ton nicht. Nutz ihn als Gerüst und schick ihn anschließend durch Weg 2 oder Weg 3. Ungeprüft übernommen ist er ein Fremdkörper, der plausibel danebenliegt.

Vier Dinge gehören rein

Die Hauptdatei heißt SKILL.md und ist die einzige Datei, die immer geladen wird. Alles darin kostet dauerhaft Platz im Kontext. Deshalb steht darin nur, was den Ablauf steuert.

1. Name und Beschreibung im Kopf der Datei. Die Beschreibung steuert, wann der Skill überhaupt anspringt.
2. Der Auslöser. Wofür ist dieser Skill zuständig, und wofür ausdrücklich nicht.
3. Die Schritte als schlichte Anweisungen. Ein Schritt, ein Satz.
4. Die Verweise. Welche Referenzdatei wird in welchem Schritt geladen.

Fünf Schritte, ein Verweis, eine Stoppregel. Mehr braucht die Hauptdatei nicht. Die Prüfkriterien selbst, alle Beispiele und der Preisrahmen liegen daneben und werden geholt, wenn sie dran sind.

Was raus muss

Dieselbe Disziplin gilt für Projekt-Anweisungsdateien. In Prompts, die halten steht die Faustprobe dafür: jede Zeile muss das Verhalten ändern, sonst raus. Für die SKILL.md gilt sie genauso, nur strenger, weil ein Skill spezifischer ist als ein Projekt.

Der Auslöser ist ein Feld, kein Zufall

Ob ein Skill anspringt, entscheidet die Beschreibung im Kopf der Datei. Sie wird gelesen, um zu prüfen, ob der Skill zur Aufgabe passt. Eine schwammige Beschreibung sorgt dafür, dass der Skill ständig mitläuft, wo er nichts zu suchen hat. Eine enge Beschreibung macht ihn steuerbar.

Wo du entscheidest, gib dir Auswahl

Bei begleiteten Skills gibt es Haltepunkte, an denen du wählst. Wenn der Agent dort einen einzigen Vorschlag liefert, beginnt das Ping-Pong: gefällt mir nicht, mach nochmal, immer noch nicht. Lass ihn stattdessen gleich mehrere Varianten liefern.

Fünf bis zehn Varianten sind der Bereich, in dem fast immer etwas Passendes dabei ist. Der Aufwand für den Agenten ist minimal, deiner sinkt von mehreren Runden auf eine Zahl.

Warum Nachladen der Unterschied ist

Der Kontext eines Agenten ist begrenzt. Alles, was drinsteht, konkurriert um Aufmerksamkeit: deine Anweisungen, die Referenzdateien, das Zwischenergebnis, der Gesprächsverlauf. Je voller es wird, desto schwächer wirken die Regeln vom Anfang.

Der übliche Fehler ist gut gemeint: Man legt dem Agenten alles hin, was er gebrauchen könnte, damit nichts fehlt. Das Ergebnis ist ein Agent, der am Anfang alles gelesen hat und in Schritt fünf nichts mehr davon präsent hat.

Die Datei kommt, wenn sie dran ist

Progressive Disclosure heißt: Die SKILL.md sagt nicht nur, dass es Referenzdateien gibt, sondern wann welche geladen wird. Der Agent holt sie im passenden Schritt und nicht vorher.

Sub-Agents halten den Dreck draußen

Manche Schritte erzeugen Müll. Eine Recherche zieht zwanzig Seiten Rohtext herein, ein Datenabruf liefert eine lange Antwort, von der drei Zeilen zählen. Dieses Material bleibt im Kontext liegen, auch wenn es längst ausgewertet ist.

Ein Sub-Agent ist die Lösung. Er bekommt den Auftrag, arbeitet in seinem eigenen Kontext und gibt nur das Ergebnis zurück. Der Rohtext bleibt bei ihm. Dein Hauptdurchlauf bekommt drei saubere Zeilen statt zwanzig Seiten.

Statisch schlägt dynamisch

Bevor du einen Live-Abruf einbaust, stell eine Frage: Ändert sich diese Information wirklich laufend? Zielgruppenprofile, Tonregeln, Preisrahmen und Prüfkriterien ändern sich alle paar Monate. Die gehören in eine Datei, nicht an eine Schnittstelle.

• Statische Datei: Kriterien, Stilvorgaben, Zielgruppen, Textbausteine, Preisrahmen
• Live-Abruf: Bestände, Termine, offene Vorgänge, tagesaktuelle Zahlen
• Im Zweifel statisch: Eine Datei, die einmal im Quartal gepflegt wird, ist schneller, günstiger und fällt nicht aus

Teste den Ablauf, nicht den Geschmack

Bei Textarbeit ist Qualität subjektiv. Ob ein Angebotsentwurf gut klingt, entscheidet kein Test. Was ein Test entscheiden kann, ist, ob die Mechanik greift.

• Laufen die Schritte in der vorgesehenen Reihenfolge, oder wird einer übersprungen?
• Wird jede Referenzdatei zum richtigen Zeitpunkt geladen, und nur dann?
• Hält der Skill an den Haltepunkten wirklich an, oder schreibt er durch?
• Greifen die Stoppregeln, wenn eine Information fehlt?
• Kommt aus dem Sub-Agenten ein kurzes Ergebnis zurück oder doch der Rohtext?

Diese fünf Fragen sind objektiv beantwortbar. Wenn sie alle passen und das Ergebnis trotzdem nicht überzeugt, liegt es am Inhalt der Referenzdateien, nicht am Ablauf. Dann weißt du wenigstens, wo du suchen musst.

Der wichtigste Prompt nach einem Fehler

Wenn der Skill danebenliegt, ist der Reflex, den Output zu korrigieren. Damit rettest du das Ergebnis und lernst nichts. Der Fehler kommt beim nächsten Lauf wieder.

Meistens kommt eine brauchbare Antwort zurück: Der Schritt war als Empfehlung formuliert statt als Anweisung. Die Bedingung war mehrdeutig. Der Verweis auf die Datei stand am Ende statt am Anfang des Schritts. Das ist die Regel, die dir gefehlt hat.

Aus Ausnahmen werden Regeln

Je öfter du den Skill benutzt, desto mehr Sonderfälle tauchen auf. Ein Angebot ohne Laufzeit. Ein Kunde mit Sonderkonditionen. Ein Entwurf, der schon geprüft war. Jeder dieser Fälle ist eine Zeile, die in den Skill gehört.

Damit das nicht an dir hängen bleibt, kannst du den Skill nach seiner eigenen Pflege fragen lassen. Wichtig ist das Fragen. Nicht jede spontane Korrektur soll zur Dauerregel werden.

Gute Ergebnisse sind Material

Wenn ein Durchlauf richtig gut war, heb das Ergebnis auf. Nicht in der SKILL.md, sondern in einer Beispieldatei, die im passenden Schritt geladen wird. Ein gutes Beispiel wirkt stärker als drei Absätze Beschreibung, weil es den Maßstab zeigt statt ihn zu behaupten.

Dieses Raster stammt aus Vom Prompt zum Loop. Was dort für den ganzen Loop gilt, gilt für den einzelnen Skill genauso: ohne Ziel, Verifikation, Stopp und Regeln läuft er zwar, aber niemand merkt, wenn er falsch läuft.

Die sechs Regeln

Wenn ein Skill nicht funktioniert

Die Skill-Bibliothek als eigentlicher Ertrag

Ein einzelner Skill spart dir eine Wiederholung pro Woche. Das ist nett. Der eigentliche Ertrag kommt später, wenn zehn davon nebeneinander liegen. Dann hast du kein Werkzeug mehr, sondern eine Ablage, in der steht, wie in deinem Bereich gearbeitet wird.

Und diese Ablage ist übertragbar. Ein Skill beschreibt einen Ablauf so genau, dass ein Agent ihn ausführen kann. Damit ist er automatisch genau genug, dass ein neuer Kollege ihn lesen und verstehen kann. Wer bisher zwei Tage Einarbeitung gebraucht hat, bekommt jetzt eine Datei.

Der nächste Schritt

Nimm den einen Kandidaten mit drei Mal ja aus Step 1. Bau ihn diese Woche. Nicht drei, nicht den kompliziertesten. Einen, den du oft genug brauchst, um ihn dreimal laufen zu lassen und dabei nachzuschärfen.

Begriffe aus dieser Lesson

• Agent Skill — Ein Agent Skill ist eine als Datei abgelegte Arbeitsanweisung, die einem KI-Agenten einen benannten, wiederholbaren Ablauf beibringt, inklusive Auslöser, Schritten und ausgelagerten Referenzdateien.
• Progressive Disclosure — Progressive Disclosure ist das Prinzip, einem KI-Agenten Zusatzwissen erst in dem Arbeitsschritt bereitzustellen, in dem er es braucht, statt alle Referenzdateien vorab in den Kontext zu laden.
• Sub-Agent — Ein Sub-Agent ist ein untergeordneter KI-Agent, der einen Teilauftrag in seinem eigenen Kontext bearbeitet und nur das Ergebnis zurückgibt, damit Rohmaterial den Hauptdurchlauf nicht belastet.