Agenten-Skills: brauchbare Regeln aus echter Arbeit

Der erste Auftrag liefert Material für die Anleitung

Im Websitebeispiel erkläre ich zunächst viele einzelne Schritte: mit dem Projekt verbinden, die vorhandene Struktur untersuchen und sich mit dem Template vertraut machen. Danach sage ich ausdrücklich, dass diese Aufgabe wiederkommen wird und daraus ein Skill entstehen soll. Das ist ein sinnvoller Zeitpunkt. Wir kennen nun einen echten Arbeitsfall, statt nur abstrakt zu vermuten, welche Anweisungen später nützlich sein könnten.

Ein solcher Skill kann festhalten, wie eine Untersuchung beginnt und welches Ergebnis sie liefern soll. Bei einer Vorlage wären das beispielsweise die benötigten Seiten, wiederkehrende Abschnitte und Elemente, die beim Anpassen erhalten bleiben sollen. Das Beispiel ist eine praktische Ableitung aus der gezeigten Arbeitsweise, keine Behauptung über den exakten Inhalt einer im Film vollständig geprüften Datei. Wichtig ist, dass eine andere Sitzung damit sinnvoll weiterarbeiten könnte.

Zu früh würde ich dagegen nicht jeden gelungen klingenden Satz als Regel speichern. Vielleicht war die Vorgehensweise nur für dieses Template passend. Vielleicht kam das Ergebnis zustande, obwohl ein Schritt falsch war. Der erste Versuch liefert deshalb eine vorläufige Anleitung. Weitere Fälle zeigen, was daran wirklich wiederverwendbar ist und was in die Projektnotizen gehört.

Ein Skill ist lesbar und damit auch kritisierbar

Im Video beschreibe ich einen Skill als Ordner mit Dateien, die sowohl Menschen als auch Maschinen lesen können. Darin stehen Anweisungen, Grenzen, Verweise und gegebenenfalls Strategien. Für mich liegt ein wichtiger Vorteil gerade in dieser Sichtbarkeit. Ich kann nachsehen, welche Vorgehensweise gespeichert wurde, und muss nicht darauf vertrauen, dass der Agent sich irgendwie an die Zusammenarbeit erinnert.

Die Größe ist dabei kein Qualitätsmaß. Eine lange Sammlung kann sich widersprechen oder das Wesentliche verstecken. Eine knappe Regel kann wiederum notwendige Bedingungen weglassen. Hilfreich ist die Frage, ob sich mit der Anleitung eine Entscheidung treffen lässt: Wann soll sie verwendet werden? Welche Quelle muss zuerst geprüft werden? Woran erkennt man, dass der Auftrag abgeschlossen ist? Ein allgemeiner Satz wie „baue eine professionelle Website“ beantwortet davon fast nichts.

Ebenso wichtig sind die Grenzen. Ein Skill über Websitearbeit sollte nicht aus einer früher erlaubten Veröffentlichung eine dauerhafte Erlaubnis für alle späteren Projekte machen. Die heutige Aufgabe bestimmt weiterhin, was getan werden darf. Diese Trennung ist meine praktische Empfehlung für den Umgang mit wiederverwendbaren Anleitungen: Wissen darf aus früherer Arbeit stammen, die aktuelle Berechtigung nicht einfach mitwandern.

Wie kürzere Aufträge überhaupt funktionieren können

Ab etwa 04:06 erkläre ich, dass die gespeicherten Anleitungen anhand passender Formulierungen aufgegriffen werden. Mein Beispiel ist ein neuer Websiteauftrag, bei dem ich um Einarbeitung in ein Template bitte. Dahinter können verschiedene vorhandene Vorgehensweisen stehen, etwa Bestandsanalyse und Recherche. Im besten Fall muss ich deren einzelne Schritte nicht erneut aufzählen, sondern kann mich auf das konkrete Projekt konzentrieren.

Das klingt bequem und hat eine Kehrseite: Eine kurze Formulierung lässt mehr unausgesprochen. Wenn der Agent den falschen Skill verwendet oder den falschen Projektstand annimmt, kann er sehr gründlich die falsche Aufgabe bearbeiten. Deshalb würde ich bei einem neuen Fall kurz sichtbar machen lassen, welche Anleitung geladen wurde und wie sie auf den Auftrag angewendet werden soll. Der zusätzliche Satz spart womöglich eine längere Korrekturrunde.

Im Film beschreibe ich meine Erfahrung so, dass die Aufträge mit der Zeit besser aufgegriffen wurden. Daraus folgt keine feste Garantie, dass jede zweite Wiederholung automatisch einen richtigen Skill erzeugt. Ebenso wenig ist „kürzer“ immer besser. Neue Ausnahmen, ein anderer Auftraggeber oder eine ungewohnte Freigabegrenze gehören weiterhin ausdrücklich in die aktuelle Anfrage. Ein Skill ersetzt wiederkehrende Erklärungen, nicht die Beschreibung des neuen Problems.

Das zweite Beispiel ist ein eigener Videoreview

Der Videofall macht den Ansatz außerhalb des Websitebaus greifbar. Ich zeige ein browserbasiertes System mit Video, Zeitleiste und Kommentaren. Mein ursprünglicher Wunsch war, an einer bestimmten Stelle eine Rückmeldung hinterlassen zu können, damit der Agent genau dort eine Änderung vornimmt. Beim ersten Aufbau mussten das System und seine Bedienung erst entwickelt und angepasst werden.

Für spätere Videos musste nach meiner Schilderung weniger davon neu aufgebaut werden. Das ist ein anderer Nutzen als bloß schneller Text. Eine wiederkehrende Produktion bekommt einen bekannten Ablauf: Material ansehen, eine Stelle benennen, eine Änderung beschreiben und das Ergebnis erneut prüfen. Der Skill kann die dabei gelernte Vorgehensweise für den nächsten Film verfügbar machen, ohne dass der alte Film als Vorlage für sämtliche Inhalte dienen muss.

Meine praktische Ergänzung dazu wäre, Rückmeldungen immer an eine konkrete Fassung und Zeitposition zu binden. Nach einem Schnitt kann dieselbe Sekunde etwas anderes zeigen. Eine gespeicherte Anleitung, die diesen Unterschied ignoriert, reproduziert sonst einen früheren Arbeitsfehler mit mehr Konsequenz. Der allgemeine Ablauf gehört in den Skill; die konkrete Videoversion und die einzelnen Kommentare bleiben beim jeweiligen Projekt.

Verbessern heißt auch Regeln wieder zu entfernen

Im Video steht die automatische Weiterentwicklung im Vordergrund. Eine Anleitung, die nur immer länger wird, ist aber nicht zwangsläufig besser. Manche Regeln sind zu speziell, andere werden durch spätere Arbeit widerlegt. Für die Pflege würde ich deshalb nicht nur fragen, was ergänzt werden soll. Ebenso wichtig ist, welche Anweisung jetzt falsch, doppelt oder irreführend geworden ist.

Ein brauchbarer Änderungsvorschlag beschreibt den beobachteten Fehler und die neue Regel getrennt. Beispielsweise: Im letzten Durchlauf wurde ein Entwurf mit der aktuellen Fassung verwechselt; künftig muss die Fassung vor dem Bearbeiten benannt werden. Danach braucht es einen echten weiteren Versuch. Erst wenn die Regel dort hilft, hat man mehr als eine plausible Erklärung aufgeschrieben. Diese Prüfung lässt sich klein halten, sollte aber nicht durch das bloße Speichern ersetzt werden.

Erfahrung ist nicht mit Modelltraining gleichzusetzen

Ich spreche im Film von Lernen und Verbesserung über mehrere Sitzungen. Gemeint ist hier die praktische Erfahrung mit gespeicherten Anleitungen und auffindbarem Kontext. Daraus sollte man nicht ableiten, dass dabei die Gewichte des verwendeten Sprachmodells trainiert werden oder jede alte Information dauerhaft richtig bleibt. Für den Anwender ist vor allem wichtig, ob die passende Quelle im richtigen Moment wieder erreichbar ist.

Die damaligen Vergleiche mit anderen Werkzeugen und Installationsmöglichkeiten sind ebenfalls keine aktuelle Funktionsübersicht. Der Beitrag soll zeigen, wie ich wiederkehrende Arbeit strukturiere. Ob ein bestimmtes Werkzeug heute automatisch einen Skill anlegt, ihn zuverlässig findet oder ein bestimmtes Modell unterstützt, muss am jeweiligen System geprüft werden. Eine persönliche gute Erfahrung ist hilfreich, ersetzt aber diesen konkreten Nachweis nicht.

Was bleibt.

Für den Einstieg würde ich einen einzigen wiederkehrenden Ablauf auswählen und nach dem nächsten echten Durchlauf eine kurze Anleitung daraus machen lassen. Lies sie selbst. Trenne allgemeine Schritte von Projektangaben, benenne Grenzen und probiere sie an einer zweiten Aufgabe aus.

Wenn du danach weniger erklären musst und das Ergebnis trotzdem genauer prüfen kannst, hat der Skill seinen Zweck erfüllt. Eine große Sammlung unbenutzter Anleitungen wäre dafür kein Ersatz.