vladyslav-betterme/autopilot-skill

Autopilot

Ein autonomer Loop, der portabel ist, weil er die Arbeit fragt, was „fertig“ bedeutet – anstatt es anzunehmen – und nicht aufhört, bis diese Antwort erfüllt ist.

Drei Behauptungen, die dieser Skill unmöglich machen soll:

• „Es funktioniert“, wenn nichts es ausgeführt hat.
• „Es ist fertig“, wenn der einzige Richter derjenige war, der es getan hat.
• „Ich habe daran gearbeitet“, ohne Aufzeichnung dessen, was versucht wurde, was fehlgeschlagen ist und warum.

Der Gegenstand spielt keine Rolle. Ein Refactoring, eine Migration, ein Bericht, ein Datensatz, ein Render-Farm, ein Cluster: Der Loop unten ist identisch und nur der Check unterscheidet sich.

0. Bootstrap – einmal pro Projekt

<skill> unten ist das Verzeichnis, in dem diese Datei liegt – .agents/skills/autopilot nach einer CLI-Installation oder wo auch immer es geklont wurde. Führe alles vom PROJEKT-ROOT aus.

node <skill>/scripts/discover.mjs        # Checks, Speicherorte, Gefahrensignale
node <skill>/scripts/bootstrap.mjs       # Erstellt das Ledger, falls nicht vorhanden
node <skill>/scripts/skills.mjs          # Die Skill-Bibliothek – wähle die Nischen dieses Projekts
node <skill>/scripts/tools.mjs           # Was diese Maschine bereits ERREICHEN kann: MCP-Server, Plugins

discover gibt den projekteigenen Check-Befehl aus. Dieser Befehl ist die Definition von „fertig“ für jede folgende Iteration.

Wenn es checks: [] ausgibt, glaube ihm noch nicht. Die Erkennung liest nur Dateien, die einen Check deklarieren; der wirkliche Check eines Projekts ist oft in Prosa benannt. Durchsuche jeden Pfad, den es unter memoryHomes aufgelistet hat, sowie die README und CI-Konfiguration, nach einem ausführbaren Befehl – bei einem Projekt stand checks: [] neben einer CLAUDE.md, die ./tests/run_all.sh nannte, was 63 Tests in vier Sekunden ausführte, während der Check, den ein Agent erfunden hätte (node --check), bei einer toten App grün war.

Erst wenn diese Suche leer zurückkommt, hat das Projekt tatsächlich keinen automatischen Check – üblich für Prosa, Forschung und Betrieb und keine Erlaubnis, die eigene Arbeit zu beurteilen. Stimme vor Iteration eins einem Akzeptanz-Check zu und schreibe ihn in das Ziel (§1). Jeder dieser Punkte ist ein Check; „Ich habe es überprüft und es sieht richtig aus“ ist keiner:

Die Arbeit	Ein Check, der nicht deine eigene Meinung ist
Code	ein Befehl, der mit Exit-Code 0 beendet, im Vordergrund ausgeführt
ein Dokument	eine aussagenweise Liste mit einer Quelle oder einem Befehl pro Aussage
Daten	eine Abfrage, die jemand anderes erneut ausführen kann und die die erwartete Form zurückgibt
Infrastruktur / Betrieb	eine Beobachtung vom System selbst, vorher und nachher
Forschung	die Abfrage oder Extraktion, die die Zahl erzeugt, plus das Ergebnis, das du IM VORAUS als widerlegend registriert hast – beide von jemand anderem wiederholbar

Lies, was die Erkennung gefunden hat, bevor du etwas anfasst:

• memoryHomes – wo dauerhaftes Wissen bereits lebt. Verwende diese Dateien. Erstelle niemals eine zweite CHANGELOG.md, ein zweites Lernverzeichnis, eine zweite AGENTS.md. Ein zweites Zuhause für eine Art von Wissen ist die häufigste Art, wie ein Agent ein Repository schlechter macht.
• signals.envFilesPresent und signals.remote – vor der ersten Iteration frage, ob die Arbeitsumgebung auf die Produktion zeigt. Das ist bei Projekten der Fall gewesen, in denen nichts im Repository darauf hinwies und jeder lokale Lauf harmlos aussah. Gehe davon aus, bis dir etwas anderes gesagt wird.
• signals.vcs – none bedeutet, dass es kein Rückgängigmachen gibt. Kopiere die Eingaben vor Iteration eins an einen sicheren Ort und gib an, wo in goal.md; §8s „committe, was grün ist“ hat hier keine Bedeutung, und genau dann geht Arbeit verloren.
• signals.dirty – uncommittete Arbeit gehört jemandem. Branche, baue niemals darauf auf.

Rüste dich vor Iteration eins

skills.mjs ist die Kurzliste öffentlicher Skills, die sich lohnen, getaggt nach Nische. Die Tags sind das Vokabular – any und review in jedem Projekt, dann web, react, db, docs, perf, a11y, mac, infra, research, design, je nachdem, was das Projekt tatsächlich benötigt.

node <skill>/scripts/skills.mjs                            # der Katalog und seine Tags
node <skill>/scripts/skills.mjs --install any --dry-run    # was es AUSFÜHREN würde
node <skill>/scripts/skills.mjs --install any              # die immer nützliche Menge
node <skill>/scripts/skills.mjs --install react,perf,db    # die Nischen dieses Projekts

Wähle aus, horte nicht. Die Beschreibung jedes installierten Skills wird bei jedem Zugriff geladen: Hundert Skills sind nicht hundert Fähigkeiten, sondern ein kleineres Fenster und ein Modell, das überfliegt.

Die Installation bedeutet, Code von Dritten mit deinen Berechtigungen auszuführen, also ist es ein angekündigter Akt: Führe zuerst --dry-run aus, sage, was du hinzufügen willst und warum, dann installiere. Wenn das Projekt zu keiner Nische im Katalog passt, ist any allein die richtige Antwort – und find-skills ist der Einstiegspunkt für eine Nische, in der der Katalog dünn ist (Forschung, Infrastruktur, Daten sind heute dünn).

Messe dann, was du gerade ausgegeben hast. skill-cleaner wird mit der any-Menge mitgeliefert und ist die Art und Weise, wie „wähle aus, horte nicht“ aufhört, ein Ratschlag zu sein:

node --experimental-strip-types <skills-root>/skill-cleaner/scripts/skill-cleaner.ts \
  --root .agents/skills --root-only --no-logs

Es meldet das Budget, das die installierten Beschreibungen belegen, Duplikate (zwei Skills, die eine Frage beantworten – der Fehler, den dieser Loop eine Ebene höher jagt) und lange Beschreibungen, die eine Komprimierung wert sind. Handle danach: Deinstalliere, was dieses Projekt nicht verwendet, und führe ein Duplikat zusammen, anstatt beide zu behalten. Ein Audit, das du liest und ignorierst, kostet denselben Kontext wie kein Audit.

Skills sind die eine Hälfte – die andere Hälfte ist die Reichweite

skills.mjs sagt, was der Agent WEISS. tools.mjs sagt, was er BERÜHREN kann: die MCP-Server, die er in den Konfigurationsdateien findet, die er zu lesen weiß, die Plugins, die mehr tragen, und was nichts auf der Platte dir sagen kann. Ein leeres Ergebnis bedeutet „nicht in diesen Dateien“, nie „nicht auf dieser Maschine“.

node <skill>/scripts/tools.mjs

Eine Fähigkeit, die dir fehlt, ist kein Grund, das Ziel zu verengen. Es ist eine Leiter – bereits erreichbar → die eigene CLI der App → ein öffentlicher Server → ein Connector (parke ihn, §6) → schreibe einen mit new-mcp.mjs. Die Sprossen, was jede kostet und die Fallen in jeder einzelnen, stehen in references/tooling.md; lies es, bevor du etwas baust, denn die zwei Fehler, die es verhindert, sind von hier aus unsichtbar: zu entscheiden, dass eine Fähigkeit fehlt, obwohl sie bereits konfiguriert ist, und eine zweite Antwort auf eine Frage zu bauen, die etwas bereits beantwortet.

Der, der dich beißen wird: Die meisten Harnesse lesen ihre MCP-Konfiguration beim START, sodass ein Server, der mid-run geschrieben wurde, für die Sitzung, die ihn schrieb, normalerweise unsichtbar ist. Deshalb ist das Gerüst auch eine CLI – node server.mjs --call <tool> '<json>', dieselben Handler. Verwende jetzt diese Form und lasse die nächste Sitzung den Server bekommen. „Weiter nach einem Neustart“ ist ein feststeckender Loop, der eine Datei hält.

Dann, durchgehend: Was du hier lernst, wird zu einem eigenen Skill (§5), geschrieben vom Loop und in derselben Sitzung verwendet – und eine Fähigkeit, die ihm fehlte, wird zu einem eigenen Tool, das auf dieselbe Weise verwendet wird.

1. Das Ziel – das Ding, bis zu dem der Loop läuft

Vor Iteration eins schreibe einen falsifizierbaren Satz und 2–5 Fertig-Kriterien auf. In goal.md oder was auch immer die Erkennung bereits als solches gefunden hat.

• Falsifizierbar: „X besser machen“ kann es nicht sein. „Jeder Pfad, der Geld ausgibt, befindet sich hinter einem expliziten Hahn, und jeder wird von einem Typ oder einem fehlschlagenden Test gehalten“ kann es sein.
• Jedes Kriterium muss von jemandem, der nicht du bist, überprüfbar sein – dieselbe Messlatte wie §0. Ein Kriterium, das nur du bestätigen kannst, ist kein Kriterium; schreibe es um.
• Unbekannte sind erlaubt, als eigene Kriterien: „Wir wissen, ob N die Ursache ist“ ist ein legitimes Fertig-Kriterium für Forschung.
• Ein großes Ziel wird durch kleine erreicht, und die Kriterien SIND diese Zerlegung – jedes ein Stück, das für sich allein landbar, überprüfbar und verifizierbar ist. Ein Kriterium, das zu groß für eine Iteration ist, wird in eigene Kriterien aufgeteilt; Tiefe ist in Ordnung, und jede Ebene behält dieselbe Messlatte (von jemandem, der nicht du bist, überprüfbar). Eine Ebene, die aufhört, falsifizierbar zu sein, ist ein Plan, kein Kriterium.
• Eine Fähigkeit, die dir fehlt, ist ein Kriterium, kein Umweg. „Der Loop kann X headless antreiben, bewiesen durch einen Round-Trip“ kommt in die Tabelle neben die Arbeit, die es freischaltet (references/tooling.md). Aufgeschrieben ist das Bauen eines Werkzeugs begrenzt und seine Abwesenheit sichtbar; nicht aufgeschrieben wird es zu einem Nachmittag, der kein Kriterium produziert hat und wie Fortschritt aussieht.
• Wenn dir niemand ein Ziel gegeben hat – „продовжуй“ und sonst nichts – ist die ERSTE Iteration die EINZIGE Ausgabe ein vorgeschlagenes goal.md und die Frage an den Menschen. Ein Kriterium, das du verfasst und dann erfüllt hast, ist Behauptung #2 oben, das eine Checkliste trägt.
• goal.md trägt auch den FESTEN Zustand: den Check-Befehl, seine Basisausgabe, die Antwort auf die Produktionsfrage, den Branch (oder wo die Kopie der Eingaben ist) und welche Skills installiert wurden. Eine Wiederaufnahme, die diese neu ableiten muss, hat nicht wieder aufgenommen.

Der Loop läuft dann, bis jedes Kriterium erfüllt UND verifiziert ist. Nicht bis das Modell sich fertig fühlt, nicht bis die Kritiker still werden – das tun sie nie. Jede Iteration endet damit, dass in goal.md markiert wird, welches Kriterium sich bewegt hat und was es beweist.

Stoppe den Loop vorzeitig nur aus den Gründen in §6 (fragen), §7 (Treiben) und §8 (Kontext).

2. Die Iteration

Eine Iteration = eine gelandete Änderung, überprüft, verifiziert, aufgezeichnet. Nicht eine Datei, nicht ein Zug.

Wähle aus. Aus den unerfüllten Kriterien des Ziels. Wenn mehrere offen sind, nimm dasjenige, dessen Fehlschlag die meiste andere Arbeit ungültig machen würde – ordne nach Risiko × Reichweite, nicht nach dem, was einfach ist.

Verstehe, bevor du kürzt. Verfolge das reale Ding Ende zu Ende. Dann frage, bevor du etwas Neues baust, ob es bereits existiert – siehe references/premise-check.md, die am höchsten ertragreichste Gewohnheit in diesem Skill und diejenige, die am längsten zu lernen brauchte.

Baue das kleinste Ding, das tatsächlich korrekt ist. Grundursache, nicht das Symptom, das der Request nennt: Finde zuerst jeden anderen Ort mit derselben Form und behebe es dort, wo sie alle durchlaufen.

Beweise. Führe den erkannten Check aus, im Vordergrund, lese den Exit-Code in der Shell, die ihn ausgeführt hat – oder besser, lass etwas, das nicht die Zusammenfassung schreibt, es für dich lesen:

node <skill>/scripts/prove.mjs --record -- npm run verify   # der Check, sein wahrer Status, in goal.md
node <skill>/scripts/prove.mjs --times 3 -- <check>         # ein Check, der mit sich selbst uneins ist, ist flaky

Prove und Verify sind die zwei Schritte, die ein Modell ERZÄHLEN kann – die anderen hinterlassen eine Datei, einen Commit oder einen Diff, während „der Check bestanden“ und „der Reviewer stimmte zu“ beide Text waren, der von dem Kontext geschrieben wurde, der sie wahr haben wollte. Der Runner beantwortet den ersten: Er startet ohne Shell, sodass der Status, den er meldet, der eigene des Kindprozesses ist; er lehnt einen Check ab, dessen eigenes npm-Skript eine Pipe enthält ("verify": "tsc | tail" meldete den Status von tail, was die Form ist, die sechs rote Deploys auslieferte, die als grün gelesen wurden); er meldet 250, wenn der Loop gestoppt wurde, 251, wenn derselbe Check zwei verschiedene Status zurückgibt, und mit --record schreibt er die Zahl die der Lauf erzeugte – einschließlich einer fehlgeschlagenen – in goal.md.

Was er nicht sehen kann: eine Pipe innerhalb eines Shell-Skripts, eines Makefile-Targets oder eines Binärprogramms, das dein Check aufruft. Er entfernt die Lüge, die er beweisen kann; er zertifiziert nicht deinen Check. §3 ist das, was für Verify antwortet – halte das Urteil und seine Beweise im Ledger fest, oder dieser Schritt ist auch Erzählung.

Führe es EINMAL VOR der ersten Iteration aus und füge das in goal.md ein: Ein Fehler, der vor dir existiert, ist eine Entscheidung zum Aufzeichnen, nicht der Fehler deiner Iteration, und ohne die Basis wirst du entweder jemand anders Rot übernehmen oder ihr Grün als Fortschritt verbuchen. Ein Check, der jemals mit sich selbst uneins war, ist flaky – führe ihn dreimal erneut aus, bevor ein Kriterium als erfüllt markiert wird. Drei Arten, wie ein Check lügt, alle beobachtet:

check | tail	meldet den Status von tail
check > log; echo "EXIT=$?"	; macht den Status zum LETZTEN Befehls – immer 0
ein hintergrundgestarteter Wrapper	die Fertigstellungsbenachrichtigung meldet den Wrapper

Wenn es keinen Befehl gibt, wird Prove nicht übersprungen und ist nicht „Ich habe es noch einmal gelesen“. Führe den Akzeptanz-Check genau so aus, wie goal.md ihn formuliert, füge seine Ausgabe ein und sage, wie ein fehlgeschlagenes Ergebnis ausgesehen hätte. Wenn du den Fehler nicht angeben kannst, hast du keinen Check.

Jede neue Absicherung braucht eine Demonstration, dass du sie fehlschlagen gesehen hast ohne den Fix. Lösche den Fix, führe ihn aus, sieh Rot, stelle wieder her. Eine Absicherung, die nicht auslösen kann, ist schlimmer als keine: Sie liest sich als Beweis, dass der Fall behandelt ist. Dieselbe Regel außerhalb des Codes – wenn der Check nicht fehlschlagen kann, ist es Dekoration.

Und wenn die Arbeit etwas EMITTIERT hat – eine Konfiguration, ein Skript, eine Unit-Datei, einen generierten Server – führe das Ding aus, das du emittiert hast. Es zu lesen beweist nichts; dreimal in einer Kampagne war der Fehler auf der Seite unsichtbar und bei der ersten Ausführung offensichtlich. Ein generierter MCP-Server sah korrekt aus und hätte seinen Client aufgehängt, weil eine JSON-RPC-Benachrichtigung keine Antwort erhalten darf. Ein Wrapper eines Carriers las sich perfekt und beendete mit 0, ohne jemals den Agenten aufgerufen zu haben, weil seine Schritte mit && verbunden waren. Ein launchd-Plist bestand plutil -lint auf beide Arten – erst launchctl bootstrap + kickstart, und dann das Lesen dessen, was es schrieb, zeigte, dass es tatsächlich lief. Emittieren ist nicht tun.

Verify – §3. Überspringe es nie, mach es nie selbst.

Lande so, wie dieses Projekt Arbeit annimmt: Commit und PR, veröffentliche, wende an, übergib. Stage mit Namen – niemals -A/-u/., sie nehmen lokale Bearbeitungen auf und -u übersieht neue Dateien. Dann überprüfe, ob das Ding tatsächlich gelandet ist: Ein grüner lokaler Lauf ist kein Deploy, und ein gemergter PR ist keine Live-Änderung.

Zeichne auf – §4. Dann aktualisiere goal.md und starte die nächste Iteration.

3. Verify mit jemandem, der die Arbeit nicht gemacht hat

Das ist nicht dasselbe wie den Check auszuführen, und es ist nicht optional.

Deine eigenen Fixes sind die zweitgrößte Quelle von Defekten – 58–68 % aller Funde in den späteren Runden einer gemessenen Kampagne, in einem Repository. Du kannst sie nicht sehen, weil das Schreiben sie ausgeschlossen hat, sie zu sehen.

• Jede Iteration: mindestens ein Unter-Agent, der die Arbeit nicht gemacht hat, mit exaktem Umfang, schreibgeschützt, dessen Aufgabe es ist, die Behauptung zu WIDERLEGEN, dass sie fertig ist. „Bestätigt“ von einem Reviewer, der nicht gesehen hat, was der Code tut – ein typischer Mensch, der nur diff liest – ist Entwurf. Der Unter-Agent führt den Check aus, hält das Urteil zusammen mit den Beweisen im Ledger fest und notiert in goal.md, ob das Kriterium tatsächlich erfüllt ist.

Ein Kriterium, das Verify nicht bestanden hat, ist nicht erfüllt. Es ist nicht „fast fertig“. Es ist in der genau gleichen Position wie vor der Iteration, minus der Sicherheit, dass jeder Schreibzugriff gültig war. Ein Kriterium, das Verify bestanden hat, aber von einem einzigen Agenten – dir – geschrieben und überprüft wurde, ist nicht bestanden: Du hast den Fehler wie üblich nicht gesehen (58–68 %).

4. Das Ledger – der Beweis, den niemand schreiben kann

goal.md weist die Richtung. Das Ledger zeichnet den Weg auf. Ohne das Ledger ist die Antwort auf „Was ist passiert?“ eine Zusammenfassung – das ist Behauptung #3 mit einem schöneren Deckblatt. Löse sie auf, indem du den Zyklus gesehen hast: Jeder Check, den der Unter-Agent gefunden hat, jedes Urteil, das ein Kriterium bestanden oder nicht bestanden hat, jeder Fehler, den das System gefunden hat, bevor Verify ihn sah.

Der Ledger-Lebenszyklus in einer Zeile:

node <skill>/scripts/ledger.mjs init               # erstellt, falls nicht vorhanden
node <skill>/scripts/ledger.mjs record <entry>      # fügt einen Eintrag hinzu
node <skill>/scripts/ledger.mjs report              # zeigt den aktuellen Stand

Die Einträge sind einfache Textdateien, eine pro Iteration, nach Zeitstempel benannt. Jeder Eintrag enthält: welches Kriterium, welcher Check, welches tatsächliche Ergebnis, welches Urteil des Unter-Agenten. Das Format ist Maschinen-lesbar genug, um einen Bericht zu generieren, und menschlich lesbar genug, um es einem Menschen zu zeigen, der fragt, warum etwas vier Iterationen gedauert hat.

Du arbeitest im Ledger. Jeder Eintrag, den du machst, ist ein Beweisstück. Jeder Eintrag, den du nicht machst, ist eine Lücke, die später eine Frage rechtfertigt. Das Ziel ist nicht „viele Einträge“, sondern „genug Einträge, damit niemand fragen muss, was passiert ist“.

5. Geschriebene Skills

Was du lernst, wird zu einem Skill – geschrieben dorthin, wo Discovery bereits platziert hat. Nicht in eine neue Datei, die ein Mensch lesen muss. In die memoryHomes-Dateien, die Discovery gefunden hat. CHANGELOG.md existiert bereits? Füge einen Eintrag hinzu. LEARNINGS.md existiert? Füge hinzu.

Wenn Discovery keine solche Datei gefunden hat, erstellt das Ledger sie – ledger.mjs init erstellt das Verzeichnis und eine index.md mit dem Namen des Projekts und dem Datum. Es ist kein zweites Zuhause; es ist das erste.

Der Inhalt eines gelernten Eintrags:

• Was war das Problem? Genug Kontext, damit jemand, der es nicht gesehen hat, es später findet.
• Was hat funktioniert? Der Befehl, der Check, der Fix. Nicht die Theorie; das Tatsächliche.
• Was hat nicht funktioniert? Die Sackgassen. Sie sind nicht Peinlichkeiten; sie sind die Grenzen, die zuerst gebaut werden, wenn dasselbe Problem zurückkommt.
• Was würde dieses Problem verhindern? Ein automatischer Check, ein Linting-Regel, eine Dokumentationsstelle. Der Samen für den nächsten Bootstrap.

Ein gelerntes Thema ohne ausführbare Verteidigung ist ein Vorschlag. Ein gelerntes Thema mit einem Check, der fehlschlägt, wenn das Problem zurückkommt, ist eine Versicherungspolice.

6. Wenn der Loop anhält

Der Loop stoppt nicht, weil ein Kriterium schwer ist. Er stoppt aus einem dieser Gründe:

• §1 (Ziel): Das Ziel ist nicht falsifizierbar. Schreibe es um, bevor du weitermachst.
• §3 (Verify): Verify ist fehlgeschlagen, und der Fehler ist nicht der Check; es ist ein echter Fehler. Markiere das Kriterium als nicht erfüllt, notiere den Fehler und starte die nächste Iteration.
• §6 (Fragen): Der Unter-Agent findet etwas, das nicht im Umfang ist. Es ist nicht deine Arbeit, aber es ist eine Information, die aufgezeichnet werden muss. Füge eine Notiz zu goal.md hinzu und fahre fort.
• §7 (Treiben): Der Loop macht Fortschritt bei einem Kriterium, aber ein anderes Kriterium, das nicht das Ziel ist, wird schlimmer. Das ist Treiben. Markiere beide und entscheide, welches wichtiger ist.
• §8 (Kontext): Der Kontext endet. Das ist das häufigste Problem. Der Loop läuft in einer Sitzung; er kann nicht über eine Sitzungsgrenze hinaus fortgesetzt werden, ohne dass eine Datei den Status hält. goal.md und das Ledger sind der Status. Wenn die Sitzung endet, stoppt der Loop. Die Wiederaufnahme ist ein neuer Loop, der die Dateien liest.

Die einzige Ausnahme: Ein Check, der "250" zurückgibt (Loop gestoppt). Das ist kein Fehler; das ist der Loop, der dem Anrufer sagt, dass er angehalten wurde. Der Unter-Agent, der den Check ausführt, erhält "250" zurück und weiß, dass er aufhören soll.

7. Treiben erkennen und stoppen

Treiben ist, wenn ein Kriterium vorrückt, aber ein anderes zurückgeht. Es ist nicht offensichtlich, weil jedes Kriterium einzellenartig ist: Du arbeitest an A, A wird besser, aber B, das du noch nicht angesehen hast, wird schlimmer, weil die Arbeit an A B unterbrochen hat.

• Jede Iteration: Überprüfe alle Kriterien, nicht nur das, an dem du gearbeitet hast. Der Unter-Agent aus §3 hat den Umfang der Arbeit – aber er hat das gesamte Ziel als Kontext. Wenn eine Änderung B bricht, muss der Unter-Agent es sehen.
• Treiben als Fehler behandeln, nicht als Entscheidung. „A war wichtiger“ ist eine Entscheidung, die nach dem Treiben getroffen wurde, nicht vorher. Vor dem Treiben zu wissen, welches Kriterium wichtiger ist, ist die richtige Reihenfolge.

8. Kontextverwaltung

Der Loop ist ein Prozess mit einem Speicher. Dieser Speicher ist die Sitzung, die ihn ausführt. Wenn die Sitzung endet, endet der Loop. Das ist in Ordnung; goal.md und das Ledger sind der Zustand. Die Wiederaufnahme ist:

1. Lese goal.md.
2. Lese das Ledger.
3. Finde das letzte Eintrags-Datum.
4. Starte die nächste Iteration ab diesem Datum.

Nicht fortsetzen: Folge dem Pfad erneut. Der Pfad ist nicht der Zustand; der Zustand sind die Dateien.

Wenn der gleiche Loop mehrmals ausgeführt wird, zum Beispiel jeden Abend, wird der Zustand zwischen den Läufen aufrechterhalten. Das bedeutet, dass ein Ziel, das nicht innerhalb einer Sitzung abgeschlossen ist, über mehrere Sitzungen hinweg fortsetzbar ist. Das ist der Sinn.

9. Fehlerbehandlung

Drei Arten von Fehlern, die der Loop sehen wird:

• Der Check schlägt fehl. (Erwartet) Der Check ist der Richter; der Richter entscheidet gegen den Kandidaten. Kein Fehler; die Iteration ist beendet, der Eintrag ist gemacht, der nächste beginnt.
• Der Check meldet 250. (Loop gestoppt) Der Loop hat eine externe Anweisung erhalten. Der Läufer stoppt sofort. Der Unter-Agent, der den Check ausführt, empfangt 250 und stoppt. Das ist kein Fehler; es ist eine Anweisung.
• Der Check ist nicht auffindbar. (Konfigurationsfehler) Der Check, den goal.md nennt, existiert nicht. Das ist kein Iterationsfehler; es ist ein Projektfehler. Der Loop stoppt und meldet den Fehler.

Keine dieser Situationen ist ein Grund, den Loop als fehlgeschlagen zu markieren. Jede ist ein Grund, den Loop zu stoppen und einen Bericht zu schreiben.

10. Metriken

Der Loop zeichnet diese Metriken im Ledger auf:

• Iterationen pro Kriterium: Wie viele Läufe hat ein Kriterium gebraucht?
• Verify-Ergebnisse: Wie oft hat Verify bestanden oder nicht bestanden?
• Fehler gefunden: Defekte, die der Check oder Verify gefunden hat, die aber nicht das Ziel waren.
• Kontextverbrauch: Geschätzte Wörter oder Token, die pro Iteration verwendet wurden (nicht genau, aber Trend ist sichtbar).

Die Metriken sind da, um den Loop zu verbessern, nicht um den Developer zu bewerten. Wenn ein Kriterium viele Iterationen braucht, ist das nicht schlecht; es ist Information.

Anhang: Befehlsreferenz

Befehl	Was er tut
node <skill>/scripts/discover.mjs	Findet Checks, Speicherorte und Gefahrensignale
node <skill>/scripts/bootstrap.mjs	Erstellt das Ledger, falls nicht vorhanden
node <skill>/scripts/skills.mjs	Listet und installiert Skills nach Nische
node <skill>/scripts/tools.mjs	Listet erreichbare MCP-Server und Plugins
node <skill>/scripts/prove.mjs	Führt einen Check aus und zeichnet das Ergebnis auf
node <skill>/scripts/ledger.mjs	Initialisiert, zeichnet auf, erstellt Bericht
node <skill>/scripts/skill-cleaner.ts	Auditiert, ob zu viele Skills installiert sind