Agenten & Skills

Agenten und Skills

0:00 Es gibt einen Moment, den fast jeder kennt, der länger mit KI-Werkzeugen arbeitet: Man fügt denselben sorgfältig formulierten Prompt zum dritten Mal ein. Spätestens dann hätte er längst irgendwo abgelegt gehört. Genau darum geht es in diesem Modul. Die CLI kennt zwei Wege, Wissen dauerhaft verfügbar zu machen — Agenten und Skills.

0:19 Beide klingen ähnlich, und beide werden regelmäßig verwechselt. Am Ende dieses Moduls können Sie sicher entscheiden, welcher der beiden zu Ihrem Problem passt, und Sie haben jeweils einen selbst geschrieben.

Spezialisten statt Universalprompt

0:32 Acht Kapitel, und sie folgen einem klaren Aufbau: Erst die Agenten, dann die Skills, jeweils zuerst das Konzept und dann die Praxis. Wir beginnen mit dem, was die CLI schon mitbringt — es lohnt sich, das zu kennen, bevor man etwas Eigenes baut. Danach schreiben wir einen eigenen Spezialisten. Und in der zweiten Hälfte kommt der Gegenspieler ins Spiel, der im Alltag inzwischen oft die bessere Wahl ist.

0:56 Der letzte Punkt ist der eigentlich schwierige. Die Formate zu schreiben ist in zehn Minuten gelernt — es sind Markdown-Dateien, mehr nicht. Die Entscheidung, wann ein Agent passt und wann ein Skill, braucht dagegen ein Verständnis davon, wie beide arbeiten. Deshalb bauen wir das Modul so auf: erst der Agent als Rolle, in die Sie hineinwechseln, dann der Skill als Anleitung, die sich von selbst meldet.

1:19 Der Unterschied klingt subtil und hat im Alltag deutliche Folgen.

Eingebaute Agenten als Spezialisten nutzen

1:23 Beginnen wir mit dem, was schon da ist. Bevor Sie etwas Eigenes schreiben, lohnt sich der Blick auf die mitgelieferten Spezialisten — einen davon haben Sie im zweiten Modul längst benutzt, ohne dass wir ihn so genannt hätten. Und es lohnt sich aus einem zweiten Grund: An den mitgelieferten Spezialisten sehen Sie, wie ein guter Agent zugeschnitten ist. Das ist die beste Vorlage für den eigenen.

1:45 Denken Sie an Handwerker. Wenn bei Ihnen zu Hause etwas kaputt ist, rufen Sie nicht „einen Handwerker", sondern je nach Schaden den Elektriker, den Klempner oder den Dachdecker. Alle drei sind kompetent, aber jeder hat andere Regeln im Kopf. Genau das ist ein Agent: ein Spezialist mit eigenen Anweisungen, eigenen Werkzeugen und eigenem Blick.

2:05 Wichtig ist die Konsequenz — solange Sie in einer solchen Rolle arbeiten, färbt sie auf jede Antwort ab. Der Plan-Modus aus dem letzten Modul war übrigens nichts anderes als so ein Spezialist. Diese Aufstellung folgt dem Lebenszyklus einer Änderung. Am Anfang steht die Planung, am Ende die Prüfung — und dazwischen liegt die Arbeit.

2:26 Interessant ist der dritte Eintrag: Er holt eine Zweitmeinung ein, indem er mehrere Modelle befragt und deren Übereinstimmungen und Widersprüche sichtbar macht. Das ist erstaunlich nah an dem, was in einem guten Team passiert, und es kostet entsprechend mehr Kontingent. Die letzte Zeile ist die praktischste: Sie zeigt den aktuellen Bestand. Verlassen Sie sich nicht auf Listen aus Tutorials — diese Werkzeuge wachsen im Monatstakt.

2:51 Der Kern steckt im ersten Punkt: Ein Spezialist ersetzt den Prompt, den sonst jeder im Team ein bisschen anders kopiert. Das ist mehr als Bequemlichkeit. Wenn drei Leute dieselbe Prüfung mit drei verschiedenen Formulierungen anstoßen, bekommen sie drei verschiedene Maßstäbe — und diskutieren hinterher über Geschmack statt über Befunde.

3:10 Der praktische Rat lautet deshalb: Nutzen Sie erst, was mitgeliefert wird. Ein eigener Agent lohnt sich erst dann, wenn Sie sagen können, worin sich Ihr Maßstab vom eingebauten unterscheidet.

Eingebaute Agenten in der Praxis

3:22 Schauen wir uns den wichtigsten davon genauer an: das Review. Es ist der Agent, den die meisten am häufigsten benutzen — und der am häufigsten falsch eingesetzt wird, nämlich in einem einzigen großen Schwung. Denn ein Review ist nur so viel wert wie die Sorgfalt, mit der man seine Ergebnisse abarbeitet. Genau daran scheitert es in der Praxis häufiger als an der Technik.

3:44 Der Review-Agent orientiert sich standardmäßig an dem, was sich geändert hat. Das ist eine kluge Voreinstellung, denn genau darum geht es beim Review: um das Neue, nicht um das Bestehende. Gibt es keine offenen Änderungen, fragt er nach — die letzten Commits oder gleich das ganze Projekt. Das Ergebnis kommt nach Schweregrad sortiert, zusammen mit dem Angebot, die Funde direkt zu beheben.

4:06 Und genau hier liegt die Versuchung, der Sie widerstehen sollten: Wer alles auf einmal beheben lässt, bekommt einen Berg von Änderungen, den niemand mehr prüft. Der rote Faden dieser Schritte ist Portionierung. Zuerst die Änderungen erzeugen und ausdrücklich nicht committen — sie sind der Prüfumfang. Dann prüfen lassen.

4:25 Und dann in Stufen arbeiten: erst das Kritische beheben, das Ergebnis ansehen, dann die nächste Stufe. Das dauert länger und ist die einzige Variante, bei der Sie am Ende noch beurteilen können, was passiert ist. Für strittige Punkte gibt es die Zweitmeinung aus mehreren Modellen — sparsam einsetzen, sie schlägt spürbar aufs Kontingent.

4:46 Diese Aufgabe hat einen Teil, der auf den ersten Blick überflüssig wirkt: einen Fund bewusst abzulehnen und die Ablehnung zu begründen. Genau das ist aber die Fähigkeit, um die es geht. Ein Review-Ergebnis ist ein Vorschlag, kein Urteil. Manche Funde treffen zu, manche gehen an Ihrem Projekt vorbei, weil sie den Kontext nicht kennen. Wer jeden Fund abarbeitet, hat die Verantwortung abgegeben.

5:10 Der eigene Commit je Stufe sorgt nebenbei dafür, dass Sie jederzeit zurückkönnen.

Eigene Agenten verstehen und einsetzen

5:16 Jetzt bauen wir selbst einen. Die gute Nachricht vorweg: Es ist weniger Aufwand, als Sie vermutlich erwarten — es gibt kein Framework, keine Registrierung, keine Installation. Eine Textdatei an der richtigen Stelle genügt, und der Spezialist steht bereit. Die eigentliche Frage ist deshalb nicht, wie man ihn schreibt, sondern was hineingehört — und was besser nicht.

5:38 Ein eigener Agent ist eine Textdatei. Das ist keine Vereinfachung für die Folie, das ist tatsächlich alles. Oben stehen ein Name und eine Beschreibung, darunter in normaler Prosa das, was dieser Spezialist wissen und beachten soll. Optional lässt sich einschränken, welche Werkzeuge er benutzen darf. Denken Sie noch einmal an den Elektriker: Sie schreiben auf, was seine Fachkunde ausmacht und was er in Ihrem Haus tun darf.

6:03 Der große Vorteil dieser Schlichtheit ist, dass die Datei ins Repository wandert — und damit versioniert und für alle sichtbar ist. Worauf es hier ankommt, sind zwei Zeilen im Kopf. Die Beschreibung ist keine Zierde, sondern die Adresse: Über sie findet das Werkzeug den Agenten, wenn Ihre Aufgabe dazu passt. Formulieren Sie sie also so, wie Sie den Bedarf formulieren würden. Die zweite ist die Werkzeugliste.

6:28 Hier steht im Beispiel bewusst nur Lesen und Suchen — ein Prüfer soll prüfen, nicht ändern. Lassen Sie die Zeile weg, darf der Spezialist alles, was Ihre Sitzung auch darf. Der Rest darunter ist gewöhnlicher Text, und genau so sollten Sie ihn auch schreiben. Der Gewinn ist vor allem organisatorisch. Der Prüfmaßstab Ihres Teams liegt nicht mehr in Chatverläufen und Notizzetteln, sondern versioniert im Repository — mit Historie, mit Pull Requests, mit Diskussion.

6:56 Die Werkzeugliste ist dabei mehr als Kosmetik: Sie ist die Antwort auf die Frage, wie viel dieser Spezialist anfassen darf. Und die beiden Ablageorte haben eine klare Arbeitsteilung. Was Ihre persönliche Arbeitsweise betrifft, gehört ins Benutzerprofil. Was der Maßstab des Projekts ist, gehört ins Projekt.

Eigene Agenten in der Praxis

7:16 Vom Schreiben zum Benutzen. Der praktische Umgang hat eine Eigenheit, die man einmal erlebt haben muss — nämlich den Rückweg. Denn das Anlegen ist schnell erledigt. Interessant wird es bei der Frage, wie ein Agent aktiviert wird, was er im aktiven Zustand mit Ihren Antworten macht und wie Sie ihn wieder loswerden. Es gibt mehrere Wege in die Rolle hinein: über die Auswahlliste, über einen direkten Hinweis im Prompt oder gleich beim Start des Programms. Der wichtigere Punkt ist der Ausstieg.

7:44 Sie bleiben in dieser Rolle, bis Sie zurückschalten — und das wird gern vergessen. Wer den Sicherheitsprüfer aktiviert lässt und danach nach einem Namen für eine Variable fragt, bekommt eine Antwort mit Sicherheitsbrille. Das ist nicht falsch, nur selten das, was man gerade wollte. Der erste Schritt ist der, den man am liebsten überspringt: prüfen, ob es das schon gibt. Danach wird es angenehm pragmatisch — lassen Sie die CLI die Datei schreiben.

8:11 Sie kennt das Format besser als jede Anleitung. Entscheidend ist der dritte Schritt: lesen und kürzen. Was so entsteht, ist meist zu lang und enthält Abschnitte, die niemand braucht. Zum Schluss taucht der Agent in der Liste auf, mit dem Vermerk, woher er stammt. Und denken Sie an den Rückweg zum Standard, wenn die Arbeit erledigt ist.

8:32 Der erste Punkt ist der häufigste: eine schwammige Beschreibung. Sie führt dazu, dass der Agent zwar existiert, aber nie gefunden wird — weder von Ihnen noch vom Werkzeug. Der zweite betrifft die Rechte. Ohne Einschränkung darf der Spezialist alles, was die Sitzung darf, und das ist bei einem reinen Prüfer selten gewollt.

8:51 Der dritte ist der vergessene Rückweg. Und der vierte räumt mit einer verbreiteten Hoffnung auf: Ein Agent ersetzt keinen Plan. Er ändert die Perspektive, nicht die Sorgfalt.

Skills verstehen und einsetzen

9:02 Wechseln wir zur zweiten Hälfte. Skills sind das jüngere Konzept, und viele, die beide kennen, greifen inzwischen häufiger zum Skill. Schauen wir uns an, warum. Das Wort klingt harmlos und meint etwas sehr Konkretes: eine Anleitung, die im richtigen Moment von selbst dazukommt. Damit verschiebt sich, wer die Initiative hat.

9:23 Ein Skill ist eine Anleitung, die sich zur richtigen Zeit selbst meldet. Stellen Sie sich ein Handbuch vor, das aufschlägt, sobald Sie die passende Aufgabe beginnen. Der Unterschied zum Agenten ist wichtig: Sie wechseln nicht die Rolle. Sie arbeiten weiter wie bisher, und das Werkzeug zieht sich das nötige Wissen dazu. Deshalb lassen sich Skills auch mitten in einer Aufgabe nutzen, ohne irgendetwas umzuschalten.

9:47 Technisch ist es ein Ordner mit einer Textdatei darin — also fast dasselbe Format wie beim Agenten, mit einer ganz anderen Wirkung. Diese Tabelle beantwortet die Frage, die im Kurs am längsten offen bleibt. Lesen Sie die erste Zeile als Schlüssel: Beim Agenten wechseln Sie hinein, der Skill bleibt im Hintergrund. Daraus folgt alles Weitere — die Auslösung, der Umfang, sogar der Platz im Kontextfenster.

10:11 Denn ein Skill belegt zunächst nur mit Name und Beschreibung Platz; der eigentliche Text kommt erst dazu, wenn er gebraucht wird. Die praktische Faustregel: Geht es um eine Haltung, nehmen Sie einen Agenten. Geht es um einen Ablauf, nehmen Sie einen Skill. Und beides schließt sich nicht aus. Zwei Punkte verdienen Hervorhebung. Der erste ist der sparsame Umgang mit dem Kontext — nach dem letzten Modul wissen Sie, warum das zählt.

10:38 Zwanzig Skills kosten Sie fast nichts, solange keiner gebraucht wird. Der zweite ist der kulturelle: Projektwissen wird teilbar. Was heute in Ihrem Kopf steckt, steht morgen im Repository und wird von jemandem genutzt, der Sie nie gefragt hat. Die Faustregel dafür ist einfach — was Sie Schritt für Schritt erklären können, taugt als Skill.

Einen Skill erstellen

10:59 Schreiben wir einen. Wie beim Agenten ist die Technik schnell erzählt. Die eigentliche Arbeit steckt an einer Stelle, die man leicht unterschätzt. Sie ist so klein, dass man sie leicht übersieht — und sie entscheidet darüber, ob der Skill je zum Einsatz kommt. Wir schauen uns deshalb genau an, was in den Kopf der Datei gehört.

11:19 Ein Ordner, eine Datei darin, ein Name in Kleinbuchstaben mit Bindestrichen — mehr Formalitäten gibt es nicht. Im Kopf stehen Name und Beschreibung, darunter die Anleitung. Und hier kommt der Punkt, den ich Ihnen ans Herz legen möchte: Die Beschreibung ist die eigentliche Arbeit, nicht der Fließtext darunter. Sie entscheidet, ob dieser Skill zur richtigen Zeit geladen wird — oder zur falschen. Nehmen Sie sich für zwei Sätze Beschreibung ruhig so lange Zeit wie für die ganze Anleitung.

11:47 Achten Sie auf die Beschreibung im Kopf. Sie sagt nicht nur, wofür der Skill da ist, sondern auch, wofür nicht. Dieser zweite Halbsatz ist ein Trick, der sich im Alltag auszahlt: Ohne ihn drängt sich ein gut beschriebener Skill in Aufgaben, die ihn nichts angehen. Der Rumpf darunter ist bewusst schlicht — eine nummerierte Liste dessen, was in diesem Projekt bei einem neuen Feature zu tun ist.

12:10 Das ist kein Programmcode, sondern aufgeschriebene Teamgewohnheit. Genau deshalb kann sie auch jemand lesen, der die CLI gar nicht benutzt. Die ersten beiden Punkte sind die zwei Fehlerrichtungen derselben Sache: Eine vage Beschreibung lädt den Skill nie oder ständig. Beides ist ärgerlich, das Zweite sogar teurer. Der dritte Punkt ist banal und kostet trotzdem regelmäßig Minuten — frisch abgelegte Skills tauchen erst nach einem Neuladen der Liste auf.

12:37 Und der vierte ist der wichtigste: Ein Skill, den die CLI für Sie geschrieben hat, beschreibt oft einen Wunschzustand statt Ihrer Wirklichkeit. Lesen, kürzen, korrigieren — sonst schreiben Sie eine Konvention fest, die es nie gab.

Einen Skill anwenden

12:51 Kommen wir zur Anwendung. Es gibt zwei Wege, und der zweite ist der, der die meisten überzeugt — weil man dabei gar nichts tun muss. Denn der zweite Weg funktioniert nur, wenn die Beschreibung stimmt. Damit schließt sich der Kreis zum vorigen Kapitel — und Sie sehen unmittelbar, ob Ihre Beschreibung taugt. Der direkte Weg ist unspektakulär: Sie nennen den Namen, der Skill wird geladen. Interessanter ist der andere.

13:16 Wenn Ihre Aufgabenbeschreibung zur Beschreibung des Skills passt, greift er von selbst — und die Ausgabe verrät Ihnen, dass er geladen wurde. Das ist der Moment, in dem der Unterschied zum Agenten greifbar wird: Sie mussten nichts umschalten und nichts wissen. Verwaltet wird der Bestand übrigens auch außerhalb der Sitzung, was für Skripte und die Einrichtung neuer Rechner praktisch ist.

13:38 Die ersten beiden Schritte sind Verwaltung, die letzten drei sind der eigentliche Umgang. Achten Sie besonders auf den vierten: In der Ausgabe nachsehen, ob der Skill wirklich geladen wurde. Denn wenn er es nicht wurde, liegt das fast nie am Werkzeug, sondern an der Beschreibung. Und damit sind wir beim fünften Schritt. Ein Skill ist nichts, was man einmal schreibt und dann liegen lässt.

13:59 Er wird besser, indem Sie beobachten, wann er greift und wann nicht — und die Beschreibung entsprechend nachschärfen. Das Erfolgskriterium ist hier bewusst anspruchsvoll: Ein Prompt ohne Nennung des Namens soll den Skill auslösen. Damit prüfen Sie nicht die Anleitung, sondern die Beschreibung — also genau die Stelle, an der die Arbeit steckt.

14:20 Der Weg dahin ist der beschriebene: erst mit Namen aufrufen, damit Sie sehen, was der Skill tut. Dann ohne Namen, und wenn nichts passiert, die Beschreibung umformulieren. Meist fehlen die Worte, die Sie selbst benutzen würden, wenn Sie die Aufgabe einem Kollegen erklären.

Weitere Skills in der Praxis

14:36 Zum Abschluss des Moduls noch ein Blick über den Code hinaus. Denn die interessantesten Skills sind oft gar keine Programmieraufgaben. Wir schauen deshalb zum Schluss über den Tellerrand: auf Abläufe, die heute mündlich weitergegeben werden und sich genauso gut aufschreiben lassen. Alles, wofür es im Team eine wiederkehrende Vorgehensweise gibt, lässt sich aufschreiben: wie Release-Notizen aussehen, wie ein neues Modul aufgesetzt wird, was beim Onboarding zu tun ist, welche Prüfliste vor einem Deployment gilt.

15:05 Nichts davon ist Code, und alles davon wird heute mündlich weitergegeben oder in einem Wiki, das niemand liest. Der Unterschied hier ist, dass die Anleitung dort liegt, wo gearbeitet wird — und sich meldet, wenn sie gebraucht wird, statt gesucht werden zu müssen. Der letzte Punkt verdient eine Anmerkung, weil er der Intuition widerspricht: Kleine, scharf beschriebene Skills schlagen einen großen Alleskönner.

15:28 Ein Skill, der alles kann, wird entweder ständig geladen oder nie — beides ist unbrauchbar. Der Nebeneffekt ist beachtlich: Wer solche Abläufe aufschreibt, dokumentiert nebenbei, wie im Projekt gearbeitet wird. Und zwar in einer Form, die niemand extra pflegen muss, weil sie im Arbeitsalltag benutzt und dadurch aktuell gehalten wird.

15:48 Der Hinweis am Ende ist der praktischste Ratschlag dieses Moduls: Nehmen Sie einen Ablauf, den Sie in den letzten zwei Wochen dreimal erklärt haben. Das ist der zuverlässigste Indikator dafür, dass sich das Aufschreiben lohnt. Vier Dinge gehören hinein — Zweck, Auslöser, Abgrenzung und Schritte. Und das Erfolgskriterium ist wieder unbequem und richtig: Ein Kollege löst den Skill aus, ohne den Namen zu kennen.

16:12 Wenn das klappt, haben Sie eine Beschreibung geschrieben, die trägt.

Wissen, das im Repo bleibt

16:17 Fassen wir zusammen. Die eingebauten Agenten decken Planung, Review und Zweitmeinung ab — bevor Sie etwas Eigenes bauen, lohnt sich der Blick dorthin. Ein eigener Agent ist eine Datei, kein Projekt. Und Skills greifen mitten in der Arbeit, wobei die Beschreibung über alles entscheidet. Was diese drei Erweiterungen verbindet, ist ihr Ort: Sie liegen im Repository und gehören damit dem Team, nicht einem Chatverlauf.

16:43 Im letzten Modul öffnen wir das Werkzeug nach außen — hin zu Daten, die kein Sprachmodell kennen kann.