Der KI-Feedback-Loop, den fast niemand aufbaut

Dein KI-Tool schreibt einen Entwurf. Du überarbeitest ihn. Du veröffentlichst. Und nächste Woche macht es exakt denselben Fehler wieder.

Das ist das Problem. Und es hat eine Lösung, die kaum jemand kennt.

Was dieser Loop macht

Die Idee ist simpel: Dein Skill schreibt einen Entwurf. Du bearbeitest ihn, veröffentlichst ihn. Dann gibst du die finale Version zurück und lässt das Tool die beiden Versionen vergleichen. Es zieht die Regeln aus deinen Änderungen raus und schreibt sie direkt in seine eigene Anleitung. Nicht als Notiz, die irgendwann vergessen wird. Sondern in die Datei, die bestimmt, wie es arbeitet.

Dein finales Edit ist der Beweis. Was du bereit warst zu veröffentlichen, ist das Einzige, das zählt.

Der Loop auf einen Blick:

  1. Dein Skill liefert einen Entwurf.
  2. Du bearbeitest ihn und veröffentlichst.
  3. Das Tool vergleicht seinen Entwurf mit deiner finalen Version.
  4. Die Änderungen, die sich wiederholen werden, landen als Regeln in der SKILL.md-Datei.
  5. Der nächste Durchlauf startet klüger. Und das Ganze beginnt von vorne.

Ich nutze das für den E-Mail-Agenten meiner Marke. Das Tool entwirft, mein Team überarbeitet, wir senden, dann liest der Agent die gesendete Version gegen seinen Entwurf. Nach zwei Monaten brauchen die Entwürfe deutlich weniger Nacharbeit. Du brauchst keine Marke dafür. Es funktioniert für Newsletter, Kundenangebote, Produkttexte, Stellenanzeigen, Werbetexte, alles, was du vor dem Veröffentlichen bearbeitest.

Warum das besser ist als „überprüf deinen eigenen Entwurf“

Ein Modell, das seine eigene Arbeit bewertet, bewertet sie nach seinem eigenen Geschmack. Und genau dieser Geschmack war das Problem. Dein Edit kommt von außen. Er interessiert sich nicht dafür, was das Modell für gut hält.

Das Setup: Zwei Ordner, eine Datei

Zwei Minuten, einmal. Danach denkst du nie wieder daran.

Die Datei. Ein Skill ist eine einfache Textdatei namens SKILL.md in einem eigenen Ordner. Das Entscheidende: Claude Code beobachtet diesen Ordner live. Eine bearbeitete Skill-Datei wirkt sofort in der laufenden Session. Kein Neustart.

Die Ordner. Erstell zwei: drafts/ und published/. Jedes Stück bekommt denselben Dateinamen in beiden Ordnern, Datum plus kurzer Titel. So findet der Agent das Paar, ohne dass du etwas erklären musst.

Wichtig zuerst: Wenn dein Skill aus einem Plugin kommt, kopiere ihn zuerst in deinen eigenen Ordner. Sonst überschreibt das nächste Plugin-Update alles, was dein Loop je gelernt hat. Ohne Warnung.

Der Loop: Drei Schritte bei jeder Veröffentlichung

Schritt 1: Den Rohentwurf speichern, bevor ihn jemand anfasst. Sobald der Agent fertig ist, muss dieser Entwurf in eine Datei. Nicht in den Chat, nicht in das Dokument, das du gleich bearbeitest. Du kannst keine zwei Versionen vergleichen, wenn du nur eine behalten hast. Füge eine Zeile in deine Skill-Datei ein: „Wenn du einen Entwurf fertigstellst, speichere ihn in drafts/ als YYYY-MM-DD-titel.md, bevor du ihn mir zeigst.“

Schritt 2: Speichern, was wirklich rausgegangen ist. Nach der Veröffentlichung kopierst du die exakte finale Version, inklusive der letzten Änderung, die jemand um 23 Uhr noch im E-Mail-Tool gemacht hat, und fügst sie in published/ mit dem passenden Dateinamen ein. Dreißig Sekunden, kein kompliziertes Tool.

Schritt 3: Den Engine-Prompt ausführen. Ein einziger Prompt erledigt den Rest. Er liest beide Versionen, listet die Unterschiede auf, behält nur die Änderungen, die sich wiederholen werden, und schreibt sie als Regeln in deine Skill-Datei, nachdem du sie freigegeben hast.

Die Datei nicht aufblähen lassen

Das ist der Teil, der diese Loops leise tötet. Monat eins ist es wunderbar: sechs klare Regeln, bessere Entwürfe. Monat vier hast du sechzig Regeln, manche sagen dasselbe zweimal, zwei widersprechen sich direkt, und der Output ist schlechter als bei Regel fünfzehn. Ein Lernloop ohne Bereinigung ist nur ein Hortungsloop.

Vier Gewohnheiten halten ihn schlank:

  • Setze ein Limit. Schreib es direkt in die Datei: „Learned Rules nie mehr als 15 Einträge.“ Wenn Regel sechzehn rein will, muss etwas raus.
  • Duplikate zusammenführen. „Intro kurz halten“ und „Einstieg auf zwei Sätze kürzen“ sind eine Regel in zwei Verkleidungen.
  • Regeln löschen, die nicht mehr auftauchen. Wenn ein Muster in den letzten 8 Vergleichen nicht aufgetaucht ist, ist es erledigt.
  • Jede Regel mit Datum versehen und regelmäßig bereinigen. Alle 10 Veröffentlichungen oder monatlich, was zuerst kommt. Niemand bereinigt freiwillig, also setz es in den Kalender.

Der Test für jede Regel

Könnte jemand, der heute Morgen angefangen hat, diese Regel befolgen, ohne eine Frage zu stellen? „Sei präziser“ scheitert. „Produktbeschreibungen haben maximal 40 Wörter“ besteht. Und wenn du deine gesamte Learned-Rules-Liste nicht in unter einer Minute vorlesen kannst, folgt der Agent ihr auch nicht wirklich.

Fünfzehn scharfe Regeln schlagen sechzig vage. Klar.

Fang diese Woche an

Du brauchst kein neues Projekt. Du brauchst eine Sache, die du bereits regelmäßig veröffentlichst und vor dem Rausgehen bearbeitest.

  1. Wähle das Stück, das du am härtesten überarbeitest.
  2. Erstelle drafts/ und published/.
  3. Speichere den nächsten Entwurf, bevor ihn jemand anfasst. Das ist der Schritt, den du vergessen wirst. Stell dir eine Erinnerung.
  4. Veröffentliche wie gewohnt, dann füge die finale Version in published/ ein.
  5. Führe den Engine-Prompt aus, streiche die Regeln, mit denen du nicht einverstanden bist, und lass den Rest in die Datei schreiben. Mach es viermal, bevor du urteilst.

Der Grund, warum das fast niemand laufen hat, ist nicht, dass es schwer ist. Es ist, weil sich das Edit fertig anfühlt, sobald du auf Veröffentlichen drückst. Ist es nicht. Jedes Edit, das du machst, ist Trainingsdaten. Und gerade wirfst du alles davon weg.


Zwei Ordner. Eine Skill-Datei. Zwei Prompts. Eine Bereinigung im Kalender. Kein Code, kein neues Abo. Speichere deinen nächsten Entwurf, bevor ihn jemand anfasst. Das ist der eine Schritt, der deine Edits in Anweisungen verwandelt, statt in nichts.