unlazy-Skill: Depth Tree gegen verfrühtes Done

Was das unlazy-Skill leistet

Das unlazy-Skill wurde entwickelt, um einen Fehler zu verhindern: Ein Coding-Agent meldet die Arbeit als abgeschlossen, bevor sie tatsächlich abgeschlossen ist. Der Kern ist der Depth Tree. Dabei wird eine Aufgabe in Ebenen aufgeteilt, und nur die unterste Ebene gilt als tatsächliche Arbeit. Version 2 verlagert die Durchsetzung aus dem Fließtext in Dateien. Der Agent muss den Abschluss daher anhand einer Liste ausführbarer Befehle nachweisen, statt ihn nur zu behaupten.

Es wird von Leonxlnx unter github.com/Leonxlnx/unlazy unter der MIT-Lizenz veröffentlicht. Diese Anleitung bezieht sich auf Version 2.0.0, veröffentlicht am 2026-08-10. Skills in diesem Bereich ändern sich schnell. Lesen Sie daher die CHANGELOG-Datei des Repositorys, bevor Sie Inhalte daraus in eine dauerhaft laufende Einrichtung übernehmen.

Ein Skill bezeichnet hier das Übliche: eine SKILL.md-Datei, die das Harness in den Kontext des Modells lädt, wenn die Aufgabe zu ihrer Beschreibung passt. Wenn dieser Mechanismus für Sie neu ist, beginnen Sie mit was ein Agent-Skill ist und wie ein Harness ihn lädt. unlazy besteht aus einfachem Markdown und einigen Node-Skripten. Es benötigt daher weder einen Server noch einen eigenen API-Schlüssel.

Warum Agenten bei 80 Prozent abbrechen und Ihre dritte Anweisung auslassen

Das Verhalten hat ein erkennbares Muster. Sie bitten um vier Dinge. Die Antwort behandelt das erste, das zweite und das vierte. Die abschließende Zusammenfassung führt alle vier als erledigt auf. Es ist kein Fehler aufgetreten, daher wurde nichts gemeldet. Eine Woche später stellen Sie die Lücke fest.

Die README von unlazy ordnet dieses Verhalten veröffentlichten Arbeiten zur Modellträgheit zu und zitiert „vorzeitiges Abschneiden von Antworten und teilweise Erfüllung mehrteiliger Anfragen“ (die Quellenangabe verweist auf arXiv 2512.20662). In derselben README wird die Designgrundlage klar formuliert: Prosa kann Prosa nicht erzwingen. Einen Agenten aufzufordern, sich mehr anzustrengen, ist weitere Prosa im selben Kontext, der die unvollständige Antwort erzeugt hat.

Deshalb speichert Version 2 ihren Status in Dateien. Ein Kontrollkästchen in GATES.md liegt außerhalb des Ermessensspielraums des Modells. Entweder enthält das Kästchen darunter eine Belegzeile oder nicht. Ein Skript kann dies feststellen, ohne den Agenten zu fragen.

Der Depth Tree, Schicht für Schicht

Der Depth Tree ist eine Zerlegung mit einer Regel dafür, wo Arbeit ausgeführt werden darf. Aus der Methodenreferenz:

An natürlichen Nahtstellen aufteilen, binär aufteilen, wenn natürliche Nahtstellen dies erlauben, N Schichten tief.

Nur Blätter sind Orte, an denen tatsächliche Arbeit ausgeführt wird. Jede darüberliegende Schicht dient der Zerlegung und Integration.

Ein Blatt ist größer als ein Aufzählungspunkt. Die Referenz legt eine Mindestgröße fest:

Ein Blatt ist eine echte Arbeitseinheit. Zehn oder mehr Minuten konzentrierte Arbeit, ein zusammenhängendes Ergebnis, eine gates-Datei.

Diese Mindestgröße verhindert, dass ein tiefer Baum zu Beschäftigungstherapie wird. Wenn ein Blatt „Variable umbenennen“ lautet, besteht es den Test nicht. Die darüberliegende Aufteilung ging dann eine Schicht zu weit.

Jedes Blatt durchläuft anschließend vier Durchgänge: vollständig und ohne Platzhalter implementieren, den Inhalt noch einmal aus der Sicht eines Fachexperten lesen, nach Fehlern suchen und anschließend kostenlos mögliche Verbesserungen umsetzen. Die Durchgänge sind ein weiterer Grund für die Mindestgröße eines Blatts. Vier Durchgänge über eine Änderung von zwei Minuten wären nur Inszenierung.

Die Tiefe wählen Sie beim Aufrufen des Skills:

/unlazy tree 5 refactor the payment module

Auch einfache Sprache funktioniert, weil die Beschreibung des Skills anhand der Absicht und nicht anhand eines Slash-Befehls abgeglichen wird:

tree 3 build the landing page and do not stop until every gate is checked

Die Referenz definiert Tiefenbereiche. tree 2 oder 3 eignet sich für ein Feature, eine Fehlersuche oder ein Dokument, das eine Person in einer Sitzung über 2 bis 4 Blätter bearbeitet. tree 4 oder 5 eignet sich für ein Subsystem, ein Refactoring oder ein gründliches Review. Dabei sind 8 bis 16 Blätter „mehr, als ein einzelner Kontext gut aufnehmen kann“. tree 6 oder 7 umfasst ein vollständiges Projekt, das im orchestrierten Modus ausgeführt wird und dessen Blätter disjunkten Arbeitseinheiten zugeordnet werden.

Wenn Sie keine Tiefe angeben, wird der Skill angewiesen, „das kleinste N zu wählen, dessen Blätter zu den natürlichen Bestandteilen der Aufgabe passen“. Außerdem wird ausdrücklich vorgegeben, standardmäßig nicht eine weitere Schicht tiefer zu gehen. Die Tiefe beschreibt die Arbeit. Eine größere Zahl verbessert daher nicht automatisch die Qualität.

So sieht eine Gates-Datei aus

Bevor Arbeiten beginnen, schreibt der Agent die Abnahmekriterien in eine Gates-Datei. Jeder Gate-Eintrag besteht aus einer Checkbox und einem darunterstehenden Befehl.

# Gates: pricing section

- [ ] G1: three tiers render with real copy
  CHECK: node check.js pricing --tiers
  EXPECT: 3/3 tiers ok
  EVIDENCE: pending

- [ ] G2: annual toggle changes both price and label
  CHECK: node check.js pricing --toggle
  EXPECT: toggle ok
  EVIDENCE: pending

CHECK ist der Befehl. EXPECT ist die Ausgabe, die als erfolgreich gilt. EVIDENCE beginnt mit pending und muss durch die tatsächliche Ausgabe des Befehls ersetzt werden. Das Skill liefert scripts/gate-check.mjs mit, um diese Dateien zu prüfen und zu melden, welche Gates noch offen sind. Dadurch können Sie einen Lauf prüfen, ohne das Transkript zu lesen.

Die Philosophie lässt sich in einem Satz zusammenfassen. SKILL.md schreibt sie ebenfalls als einen Satz:

Ein Bericht ist eine Menge von Aussagen, die durch ein Protokoll belegt sind, und kein bloßes Gefühl, dass alles abgeschlossen ist.

Daraus folgt die Regel „kein Bericht, bevor das Protokoll vollständig ist“. Außerdem gilt: Jede Zahl in einer abschließenden Zusammenfassung wird zum Zeitpunkt der Berichterstellung erneut gemessen oder als nicht verifiziert gekennzeichnet. Ein Gate kann nicht geschlossen werden, weil der Agent sich fertig fühlt. Zum Schließen muss eine Ausgabe eingefügt werden, die entweder mit EXPECT übereinstimmt oder nicht.

Schreiben Sie Gates, die eine fremde Person ausführen könnte. „Sieht gut aus“ ist keine Prüfung. test -s dist/index.html && echo ok mit der Ausgabe ok auszuführen, ist eine Prüfung, weil der Befehl bei einer leeren oder fehlenden Datei eindeutig fehlschlägt.

Der Vertrag in PLAN.md vor jeder parallelen Arbeit

Sobald ein Baum breit genug ist, dass Blätter in getrennten Kontexten ausgeführt werden, teilen diese Blätter keine gemeinsamen Annahmen mehr. Die Methodenreferenz stellt dem Fan-out einen Vertrag voran:

Verträge vor dem Fan-out. Schnittstellen, Datenbesitz, Namenskonventionen und Fehlerkonventionen werden in PLAN.md festgelegt, bevor ein Blatt startet.

Der Grund ist konkret. Zwei Subagenten, die jeweils die Anweisung „Fehlerbehandlung hinzufügen“ erhalten, erfinden zwei unterschiedliche Fehlerstrukturen. Beide Blätter passieren ihre eigenen Prüfungen, weil jedes für sich korrekt ist. Der Fehler zeigt sich erst an der gemeinsamen Schnittstelle. Dafür gibt es Branch-Gates: Die Gates eines Branches weisen nach: „Kinder zusammengeführt, Schnittstellen stimmen überein, End-to-End-Verhalten funktioniert, keine Regressionen in Geschwister-Branches.“

Im orchestrierten Modus übergibt der Treiber jedem Subagenten den Vertragsabschnitt aus PLAN.md, nicht die gesamte Datei und nicht die eigene Historie des Treibers. Zusätzlich übergibt er die Gates-Datei des jeweiligen Blatts unverändert. Wenn der Subagent zurückkehrt, führt der Treiber die Prüfungen selbst erneut aus. Ein Subagent, der „seine eigenen Punkte ohne Nachweise abgehakt“ hat, wird mit einer konkreten Auflistung der nicht erfüllten Gates zurückgeschickt.

Die Orchestrierung hat eine Untergrenze. Bei weniger als ungefähr einer halben Stunde tatsächlicher Arbeit empfiehlt die Referenz, allein zu arbeiten. Jeder Subagent muss das Verständnis der Aufgabe von Grund auf neu aufbauen. Dieser Einrichtungsaufwand ist höher als der Nutzen der zusätzlichen Aufmerksamkeit.

Wie installiert man das unlazy-Skill?

Der unterstützte Weg führt über die skills CLI:

npx skills add Leonxlnx/unlazy

Bei der manuellen Installation wird das Repository in das Skills-Verzeichnis Ihres Agents geklont:

git clone https://github.com/Leonxlnx/unlazy ~/.claude/skills/unlazy

git clone https://github.com/Leonxlnx/unlazy ~/.codex/skills/unlazy

Prüfen Sie anschließend, ob die Datei dort vorhanden ist:

ls ~/.claude/skills/unlazy/SKILL.md

Wenn der Pfad ausgegeben wird, liegt die Datei auf dem Datenträger. No such file or directory bedeutet, dass der Klon an einem anderen Ort erstellt wurde. Das passiert normalerweise, wenn das Skills-Verzeichnis nicht unter dem von Ihnen angenommenen Namen vorhanden war und git ein neues Verzeichnis angelegt hat. Verlassen Sie sich auch nicht allein auf die Aussage des Agents. Der Installationshinweis in der README endet mit derselben Warnung: "Do not tell me it is installed unless you have actually verified the file is on disk."

Bei einem Harness ohne Skill-Loader fügen Sie den Inhalt von SKILL.md in den System-Prompt oder die Regeldatei ein. Das ist der dokumentierte Fallback. Deshalb funktioniert die Methode mit Claude Code, Codex, Cursor und allen anderen Systemen, die eine einfache Markdown-Anweisungsdatei lesen. Wenn Sie wissen möchten, wodurch ein SKILL.md zuverlässig geladen wird, beschreibt ein eigenes Agent-Skill schreiben das Frontmatter und den Abgleich der Beschreibung. Diese entscheiden, ob das Skill überhaupt ausgelöst wird.

Funktioniert der Stop-Hook außerhalb von Claude Code?

Nein. Dieser Punkt muss genau unterschieden werden. Alles oben sind Anweisungen, und Anweisungen können ignoriert werden. Die einzige strukturelle Durchsetzung erfolgt über einen Stop-Hook. Stop-Hooks sind eine Funktion von Claude Code.

node <path-to-skill>/scripts/install-hooks.mjs            # this project only (settings.local.json)
node <path-to-skill>/scripts/install-hooks.mjs --global   # every project
node <path-to-skill>/scripts/install-hooks.mjs --uninstall

Ein Stop-Hook wird ausgeführt, sobald der Agent versucht, seinen Zug zu beenden. Dieser Hook prüft die Gate-Dateien und verhindert das Beenden, solange Gates noch nicht erfüllt sind. Dadurch kann der Zug nicht mit einer ungeprüften Checkbox enden. Der Hook liest Dateien und führt keine Modellaufrufe aus. Deshalb steht in der README, dass er null Tokens kostet. Informationen zum allgemeinen Mechanismus und zu den anderen Ereignissen, an die Sie Hooks binden können, finden Sie unter wie Claude-Code-Hooks während eines Zugs ausgelöst werden.

Der Hook verfügt über eine Ausstiegsmöglichkeit. Das ist wichtiger, als es zunächst klingt. Wenn der Agent bei sechs aufeinanderfolgenden blockierten Stop-Versuchen keinen Fortschritt bei den Gates macht, lässt der Hook ihn mit einer Warnung weiterlaufen, anstatt ihn festzuhalten. Eine ABANDON: <gate> <reason>-Zeile wird immer als regulärer Ausstieg akzeptiert. Ohne diese beiden Ausnahmen würde ein Gate, das in Ihrer Umgebung nicht erfüllt werden kann, so lange Tokens verbrauchen, bis Sie die Sitzung selbst beenden.

In Codex, Cursor oder einem anderen Harness kann install-hooks.mjs nichts installieren. Sie erhalten weiterhin die Gate-Datei und die ausführbaren Prüfungen. Es gibt jedoch keine strukturelle Sperre, die das vorzeitige Beenden des Zugs durch das Modell verhindert. Dort ist die Gate-Datei ein Dokument, das Sie lesen müssen.

unlazy oder ponytail: Welche Variante möchten Sie?

Diese beiden Skills waren in derselben Saison im Trend und wirken sich beim Umfang in entgegengesetzte Richtungen aus. Dadurch lassen sie sich leicht verwechseln.

ponytail lässt den Agenten wie einen erfahrenen Entwickler handeln, dessen erste Frage lautet, ob der Code überhaupt benötigt wird. Der Skill reduziert den Umfang, bevorzugt die Standardbibliothek und verkleinert den Diff. unlazy setzt voraus, dass der Umfang bereits festgelegt ist, und erhöht den Aufwand, bis jeder Teil umgesetzt und nachgewiesen ist.

Wählen Sie daher anhand des tatsächlichen Fehlers. Wenn Ihr Agent aus einer kleinen Funktionalität ein Framework macht, benötigen Sie den ponytail-Skill und seine Persona eines faulen Senior-Entwicklers. Wenn Ihr Agent den dritten Punkt einer vierteiligen Anforderung unbearbeitet lässt und anschließend Erfolg meldet, benötigen Sie unlazy.

Beide Skills können gleichzeitig ausgeführt werden. Die Reihenfolge ist entscheidend. Legen Sie den Umfang zuerst mit ponytails Frage fest und übergeben Sie den vereinbarten Umfang anschließend an die Prüfungen von unlazy. Gehen Sie umgekehrt vor, bauen Sie einen Baum aus Blättern für Arbeit auf, die ponytail gelöscht hätte, und wenden anschließend den Tiefenmultiplikator auf alles an. Diese Reihenfolge ist meine Empfehlung und keine dokumentierte Integration zwischen den beiden Projekten.

Welche Kosten verursacht die Tiefe bei einem auf einem VPS gehosteten Agenten?

Tiefe ist ein Aufwandsmultiplikator, und Aufwand wird in Tokens gemessen. Wenn ein Agent auf einem VPS mit Ihrem eigenen API-Schlüssel läuft, bedeutet dieser Multiplikator höhere Kosten.

[
  {
    "label": "Skill run vs no skill, output tokens",
    "low_multiplier": 1.6,
    "high_multiplier": 3.9
  },
  {
    "label": "tree 6 vs tree 3, total cost",
    "low_multiplier": 1.0,
    "high_multiplier": 1.5
  }
]

Das sind die Zahlen der Autoren aus ihrem eigenen Test vom 2026-08-10. Wir haben sie nicht reproduziert. Betrachten Sie sie daher als Größenordnung und nicht als Prognose. Disziplin im Solo-Modus steigerte die Ausgabe auf ungefähr das 1.6- bis 3.9-Fache der Basislinie. Der Wechsel von Tree 3 zu Tree 6 innerhalb eines Kontexts fügte dagegen nur das 1.0- bis 1.5-Fache hinzu. Das liegt deutlich unter dem Achtfachen, das Sie bei drei weiteren binären Aufteilungen erwarten würden.

Eine größere Tiefe ist nicht proportional teurer, weil sie den Aufwand verteilt, anstatt weitere Kontexte hinzuzufügen. Die Referenz zur Token-Ökonomie benennt den tatsächlichen Multiplikator klar: „Die Orchestrierung multipliziert die Kosten. Das ist auch sinnvoll, weil jedes Blatt einen neuen Kontext erfordert.“ Der Solo-Modus multipliziert die Ausgabetokens innerhalb eines Kontexts. Der orchestrierte Modus multipliziert die Kontexte. Jeder neue Kontext liest den Vertrag und die gates-Datei erneut, bevor er etwas Nützliches ausführt.

Es gibt einen zweiten Kostenfaktor, der leicht übersehen wird und den dieselbe Referenz nennt. Ein einzelner monolithischer Lauf mit großer Tiefe „verbrauchte in ihrem Test ungefähr 58 Millionen gecachte Input-Tokens“, weil ein einziger ständig wachsender Kontext alle Informationen enthielt. Gecachter Input ist pro Token günstiger. Bei diesem Volumen erscheint er trotzdem auf der Rechnung.

Daraus ergeben sich vier Einstellungen:

• Wählen Sie die kleinste Tiefe, deren Blätter echte Arbeitseinheiten sind, und beenden Sie den Lauf dann. Nicht benötigte Tiefe verursacht nicht benötigte Kosten.
• Verwenden Sie bei einer Arbeitsdauer von weniger als einer halben Stunde den Solo-Modus. Die Einrichtung eines Subagents kostet dort mehr, als der neue Kontext einbringt.
• Installieren Sie den Stop-Hook, wenn Sie Claude Code verwenden. Das ist der einzige Teil dieses Verfahrens, der kostenlos ausgeführt wird.
• Legen Sie auf Kontoebene ein hartes Ausgabenlimit fest, bevor Sie einen längeren Lauf starten.

Der letzte Punkt ist der entscheidende. Ein Skill, der frühe Abbrüche absichtlich ablehnt, arbeitet auch absichtlich weiter. Budgets und Benachrichtigungen sind eine separate Aufgabe vom Prompting. Die Kosten eines Agenten auf einem VPS unter Kontrolle halten erklärt, welche Limits Sie zuerst einrichten sollten.

Was die Autoren gemessen haben und was dies belegt

Das Repository veröffentlicht einen eigenen Test. Das ist seltener, als es sein sollte. Der Aufbau wird aus der README zitiert: „zwei Build-from-Scratch-Aufgaben (eine Marketing-Website und ein dreidimensionales Sonnensystem mit three.js), jeweils drei Bedingungen (ohne Skill, tree 3, tree 6), pro Durchlauf ein neuer Ordner und eine neue Sitzung, dasselbe Modell und derselbe Prompt-Text. Jede Ausgabe wurde von unabhängigen Agents per Code-Review geprüft, anschließend gezielt erneut verifiziert und in einem Browser live getestet.“

[
  {
    "label": "Self-found defects fixed, skill runs",
    "low_count": 4,
    "high_count": 10
  },
  {
    "label": "Wrong numbers in report, skill runs",
    "low_count": 1,
    "high_count": 3
  },
  {
    "label": "Wrong numbers in report, baseline runs",
    "low_count": 0,
    "high_count": 0
  }
]

Lesen Sie die mittlere Zeile zweimal. Im eigenen Test der Autoren führt der Skill dazu, dass der Agent vor der Auslieferung 4 bis 10 Fehler selbst findet. Jeder Skill-Durchlauf lieferte danach einen abschließenden Bericht mit 1 bis 3 falschen Zahlen. In den Baseline-Durchläufen waren es 0. Mehr Arbeit erzeugte bessere Builds und schlechtere Zusammenfassungen. Das ist die Erkenntnis hinter der Ledger-Regel und hinter der Anweisung, jede Zahl zum Zeitpunkt der Berichterstellung erneut zu messen oder sie als unverifiziert zu kennzeichnen.

Ein weiteres Ergebnis sollten Sie festhalten: „Der einzige harte Live-Fehler trat bei einem Baseline-Build auf, und der zugehörige Bericht behauptete, der Fall sei bearbeitet worden.“ Eine selbstsichere Zusammenfassung über einem fehlerhaften Build ist genau das Problem, gegen das die Gates gerichtet sind.

Nun zu den Grenzen. Sechs Durchläufe, zwei Build-Aufgaben und ein Modell, ausgeführt und berichtet vom Autor des Skills selbst. Nichts davon ist eine unabhängige Replikation. Wir geben dies als Behauptungen der Autoren mit Stand vom 2026-08-10 wieder. Testen Sie es stattdessen an Ihrer eigenen Arbeit: Führen Sie dieselbe Aufgabe zweimal aus, einmal ohne weitere Vorgaben und einmal mit einer Gates-Datei. Zählen Sie anschließend die Gates, die mit selbst erneut ausführbaren Nachweisen geschlossen wurden. Diese Anzahl ist die einzige Zahl in diesem Bereich, die Ihnen gehört.

FAQ

Was ist der Depth Tree im Skill unlazy?

Dabei handelt es sich um eine Dekompositionsmethode. Eine Aufgabe wird an natürlichen Schnittstellen über N Ebenen aufgeteilt. Nur die Blätter auf der untersten Ebene zählen als Arbeit. Der Skill definiert ein Blatt als mindestens zehn Minuten konzentrierte Arbeit mit einem zusammenhängenden Ergebnis und einer Gates-Datei. Ein Blatt, das Sie in zwei Minuten abschließen könnten, bedeutet daher, dass die Aufteilung eine Ebene zu tief ging. Jede Ebene über den Blättern dient der Dekomposition und Integration. Jeder Zweig enthält eigene Gates, die belegen, dass die untergeordneten Aufgaben zusammengeführt wurden und die Schnittstellen übereinstimmen. Sie wählen die Tiefe beim Aufruf aus, beispielsweise mit tree 5. Der dokumentierte Standard ist die kleinste Tiefe, deren Blätter tatsächliche Arbeitseinheiten sind.

Funktioniert der Skill unlazy außerhalb von Claude Code?

Teilweise. Der Skill besteht aus einfachem Markdown. Daher können Codex, Cursor und alle Systeme, die eine SKILL.md oder einen System-Prompt lesen, den Depth Tree, die Gates-Datei, die ausführbaren Prüfungen und die vier Durchläufe pro Blatt verwenden. Die strikte Durchsetzung unterscheidet sich jedoch. Der Stop-Hook, der das Ende eines Durchlaufs verhindert, solange Gates nicht erfüllt sind, ist eine Funktion von Claude Code und wird mit node <path-to-skill>/scripts/install-hooks.mjs installiert. In allen anderen Umgebungen verhindert strukturell nichts, dass das Modell seinen Durchlauf vorzeitig beendet. Sie müssen daher die Gates-Datei selbst prüfen und zurücksenden.

Wie stark erhöht der Skill unlazy meine Tokenkosten?

Die Autoren geben für den Einzelmodus 1.6 bis 3.9 mal so viele Ausgabetokens wie bei einem Durchlauf ohne Skill an. Hinzu kommen einige hundert Tokens für die Gates-Datei selbst. Eine größere Tiefe innerhalb eines Kontexts ist im Vergleich fast kostenlos. Beim Wechsel von Tree 3 zu Tree 6 sind es etwa 1.0 bis 1.5 mal so viele Tokens. Der orchestrierte Modus ist teuer. Für jedes Blatt wird ein neuer Kontext gestartet, der den Vertrag und die zugehörigen Gates erneut liest, bevor er arbeitet. Der Stop-Hook verursacht keine zusätzlichen Kosten, da er nur Dateien scannt. Dies sind die Angaben der Autoren vom 2026-08-10 und keine Messwerte, die wir selbst wiederholt haben.

Sollte ich unlazy oder ponytail verwenden?

Richten Sie den Skill nach dem vorliegenden Fehlerbild. ponytail ist für einen Agenten gedacht, der zu viel schreibt. Der Agent verhält sich wie ein Senior Developer, prüft, ob der Code überhaupt erforderlich ist, und verwendet zuerst die Standardbibliothek. unlazy ist für einen Agenten gedacht, der zu wenig von Ihrer Aufgabe abschließt. Der Skill erzwingt die Dekomposition und lässt ein Gate ohne Nachweis nicht schließen. Wenn Sie beide verwenden möchten, begrenzen Sie den Umfang zuerst mit ponytail. Übergeben Sie diesen Umfang anschließend an unlazy. So wenden Sie keinen Aufwandsmultiplikator auf Arbeit an, die hätte entfallen sollen.

Warum beendet mein Agent seine Arbeit nach der Installation von unlazy weiterhin vorzeitig?

Prüfen Sie vier Punkte. Erstens muss der Skill mit ls ~/.claude/skills/unlazy/SKILL.md auf dem Datenträger vorhanden sein. Ein Klon in ein Verzeichnis, das nicht vorhanden war, ist die häufigste Ursache. Zweitens muss vor Beginn der Arbeit eine Gates-Datei erstellt worden sein. Der Hook scannt Gates-Dateien. Eine fehlende GATES.md-Datei kann daher nichts blockieren. Drittens müssen Sie prüfen, wo der Hook installiert wurde. Der einfache Aufruf install-hooks.mjs schreibt nur in die settings.local.json dieses Projekts. Für ein anderes Projekt benötigen Sie --global. Viertens funktioniert die Notfallfreigabe wie vorgesehen. Nach sechs aufeinanderfolgenden blockierten Stopps ohne Fortschritt bei den Gates darf der Agent mit einer Warnung fortfahren. Eine Zeile mit ABANDON: <gate> <reason> beendet den Versuch absichtlich.