unlazy-Skill: Depth Tree gegen zu frühes Fertigmelden

Welche Aufgabe das unlazy-Skill erfüllt

Das unlazy-Skill verhindert einen bestimmten Fehler: Ein Coding-Agent meldet die Arbeit als abgeschlossen, obwohl sie noch nicht abgeschlossen ist. Kernbestandteil ist der Depth Tree. Dabei wird eine Aufgabe entlang ihrer tatsächlichen Grenzen aufgeteilt, und jedes Blatt erhält eigene Abnahmekriterien. In Version 2 wurde die Durchsetzung aus dem Fließtext in Dateien verlagert. Der Agent muss den Abschluss daher anhand einer Liste ausführbarer Befehle nachweisen, statt ihn nur zu behaupten.

Das Skill wird von Leonxlnx unter github.com/Leonxlnx/unlazy unter der MIT-Lizenz veröffentlicht. Es gibt keine markierte Version, auf die Sie fest pinnen können: Am 2026-10-11 waren sowohl die Tag- als auch die Release-Liste des Repositorys leer. Dieser Leitfaden wurde zunächst anhand des Quelltext-Meilensteins 2.0.0 vom 2026-08-10 erstellt. Am 2026-10-11 wurde er erneut anhand des aktuellen Quelltexts auf main geprüft. Das CHANGELOG bezeichnet diesen Quelltext als „Unreleased, target 2.1.0“ und weist darauf hin, dass für 2.1.0 kein Git-Tag und kein GitHub-Release beansprucht wird. Wenn Sie heute den Installationsbefehl ausführen, erhalten Sie diesen neueren Quelltext und nicht 2.0.0. Skills in diesem Bereich ändern sich schnell. Lesen Sie daher das CHANGELOG des Repositorys, bevor Sie Inhalte aus diesem Leitfaden in eine dauerhaft betriebene Umgebung übernehmen.

Ein Skill ist hier im üblichen Sinn eine SKILL.md-Datei, die der Harness in den Kontext des Modells lädt, wenn die Aufgabe zu ihrer Beschreibung passt. Falls 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 Agents bei 80 Prozent abbrechen und Ihre dritte Anweisung auslassen

Dieses Verhalten folgt einem erkennbaren Muster. Sie bitten um vier Dinge. Die Antwort behandelt den ersten, den zweiten und den vierten Punkt. Die abschließende Zusammenfassung führt alle vier als erledigt auf. Es ist kein Fehler aufgetreten, daher wurde nichts gemeldet, und Sie entdecken die Lücke erst eine Woche später.

Die README von unlazy ordnet dieses Verhalten veröffentlichter Forschung zur Modellträgheit zu. Sie verweist auf arXiv 2512.20662 und die Feststellung, dass „detaillierte mehrteilige Prompts bei getesteten Modellen weiterhin nur teilweise befolgt werden und vorzeitig abbrechen“. Der Abschnitt zu den Gates formuliert die Designprämisse klar: „Die obigen Regeln sind Prosa, und Prosa ist die Ebene, die dieses Projekt bereits als die schwächste behandelt.“ Einen Agent aufzufordern, sich stärker anzustrengen, bedeutet mehr Prosa im selben Kontext, der bereits zur unvollständigen Ausführung geführt hat.

Deshalb speichert Version 2 ihren Status in Dateien. Ein Kontrollkästchen in GATES.md liegt außerhalb des Ermessensspielraums des Modells. Entweder befindet sich unter dem Gate ein entsprechender Nachweis oder nicht. Ein Script kann das feststellen, ohne den Agent zu fragen.

Der Depth Tree, Schicht für Schicht

Der Depth Tree ist eine Zerlegung mit einer Regel dafür, an welchen Stellen Aufteilungen zulässig sind. Aus der Methodenreferenz:

Teilen Sie nur an echten Grenzen zwischen Domänen, Komponenten oder Verifikationsschritten. Binäre Aufteilungen sind optional.

Machen Sie Ebene 1 zur angeforderten Aufgabe.

Die Blätter enthalten die Ergebnisse. Jede darüberliegende Ebene integriert und verifiziert die Rückgaben ihrer untergeordneten Elemente.

Ein Blatt ist größer als ein Aufzählungspunkt. Die Referenz bemisst es anhand des Ergebnisses, nicht anhand der Zeit:

Machen Sie jedes Blatt zu einem zusammenhängenden Ergebnis.

Führen Sie kleine benachbarte Blätter zusammen. Teilen Sie ein Blatt auf, das mehrere unabhängige Ergebnisse verbirgt.

Diese Regel verhindert, dass ein tiefer Baum zu Beschäftigungstherapie wird. Wenn ein Blatt „Variable umbenennen“ lautet, besteht es den Test nicht, und die darüberliegende Aufteilung ging eine Ebene zu weit.

Jedes Blatt durchläuft anschließend vier Durchgänge: Implementieren Sie es vollständig und ohne Platzhalter, lesen Sie es erneut so, wie es ein Fachexperte tun würde, suchen Sie nach Fehlern und nehmen Sie anschließend Verbesserungen vor, wenn diese mit geringem Aufwand möglich sind. Wiederholen Sie den Ablauf, bis ein vollständiger Verbesserungsdurchgang nichts mehr findet. Diese Durchgänge sind ein weiterer Grund, kleine Blätter zusammenzuführen. Vier Durchgänge über eine zweiminütige Änderung wären reine Beschäftigungstherapie.

Sie wählen die Tiefe beim Aufrufen der Fähigkeit:

/unlazy tree 5 refactor the payment module

Auch natürliche Sprache funktioniert, weil die Beschreibung der Fähigkeit anhand der Absicht und nicht anhand eines Slash-Befehls abgleicht:

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

Frühere Versionen dieses Leitfadens nannten Tiefenbereiche mit einer Blattanzahl für jede Tiefe. Die aktuelle Methodenreferenz enthält überhaupt keine Blattanzahlen und sagt: „Betrachten Sie die Tiefe nicht als arithmetische Zusage über Aufwand oder Token.“ Übrig bleibt nur die qualitative Empfehlung: „Verwenden Sie für ein Feature, eine begrenzte Fehlersuche oder ein Dokument einen flachen Baum oder ein Solo-Arbeitsprotokoll.“ Ein orchestrierter Baum ist für Fälle vorgesehen, in denen mehrere zusammenhängende Ergebnisse von neuen Kontexten oder unabhängiger Zuständigkeit profitieren. Eine größere Tiefe ist nur dann gerechtfertigt, wenn ihre zusätzlichen Zweige echten Integrationsgrenzen entsprechen.

Wenn Sie keine Tiefe angeben, sagt die Referenz, Sie sollen „den kleinsten Baum wählen, der jedes unabhängige Ergebnis und jeden Integrationspunkt sichtbar macht“. Wenn Sie eine Zahl angeben, die nicht zur Aufgabe passt, soll der Agent dies angeben, statt den Baum künstlich aufzufüllen: „Wenn die angeforderte Tiefe zu Füllblättern führen würde, nennen Sie die Abweichung und verwenden Sie die nächstliegende ehrliche Zerlegung.“ Die Tiefe beschreibt die Arbeit. Eine größere Zahl verbessert daher nicht automatisch die Qualität.

So sieht eine Gates-Datei aus

Bevor die Arbeiten beginnen, schreibt der Agent die Abnahmekriterien in eine Gates-Datei. Jeder Gate-Eintrag besteht aus einer Checkbox mit 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. Zusätzlich muss der Befehl mit Exit-Code 0 beendet werden. EVIDENCE beginnt bei pending. Nach einem erfolgreichen Lauf trägt der Prüfer dort statt der Rohdaten einen Fingerabdruck der Ausgabe ein. Ein manueller Gate-Eintrag enthält keinen Befehl. In diesem Fall wird die kleinste Tatsache dokumentiert, die das Ergebnis belegt. Das Skill liefert scripts/gate-check.mjs dafür. Mit --status wird angezeigt, welche Gate-Einträge noch offen sind, ohne einen Befehl auszuführen oder eine Datei zu ändern. Dadurch können Sie einen Lauf prüfen, ohne das Protokoll zu lesen. Ledger-Befehle werden nur ausgeführt, wenn Sie --approve übergeben. Lesen Sie daher jeden Befehl und jedes aufgerufene Script, bevor Sie dieses Argument übergeben. Ein separates scripts/gate-lint.mjs prüft die Qualität eines Ledgers, ohne etwas auszuführen.

Die Reporting-Regel in SKILL.md passt in eine Zeile:

Erstellen Sie keinen Abschlussbericht, solange ein erforderlicher Gate-Eintrag nicht erfüllt, aufgegeben, zurückgestellt oder Gegenstand einer ausstehenden Entscheidung des Verantwortlichen ist.

Zusätzlich wird der Agent angewiesen, "jede Zahl und jede Aussage zum Abschluss unmittelbar vor der Berichterstellung erneut zu messen". Ein Gate-Eintrag kann nicht geschlossen werden, nur weil der Agent die Arbeit für abgeschlossen hält. Zum Schließen ist ein Lauf erforderlich, dessen Ausgabe entweder EXPECT entspricht oder nicht.

Schreiben Sie Gates, die eine andere Person ausführen könnte. "Sieht gut aus" ist keine Prüfung. test -s dist/index.html && echo ok, das ok ausgibt, ist eine Prüfung, weil der Befehl bei einer leeren oder fehlenden Datei einen eindeutigen Fehler meldet.

Der Vertrag in PLAN.md vor paralleler Arbeit

Sobald ein Baum so breit ist, dass Blätter in separaten Kontexten ausgeführt werden, teilen diese Blätter keine Annahmen mehr. Die Methodenreferenz stellt vor der Aufteilung einen Vertrag voran: „Verträge vor der Aufteilung festlegen.“ Der Plan listet jedes erforderliche Ergebnis in PLAN.md auf. „Danach werden Schnittstellen, Formate, gemeinsame Annahmen, Fehlerkonventionen, Benennung und Zuständigkeit festgehalten, bevor ein Blatt startet.“

Der Grund ist konkret. Zwei Subagents, die jeweils angewiesen werden, „Fehlerbehandlung hinzuzufügen“, erfinden zwei unterschiedliche Fehlerformate. Beide Blätter bestehen ihre eigenen Prüfungen, weil jedes lokal korrekt ist. Der Fehler zeigt sich erst an der Stelle, an der beide zusammenkommen. Diese Verbindungsstelle gehört zur übergeordneten Ebene. Die Orchestrierungsreferenz beschreibt den Ablauf ausdrücklich: „Die untergeordneten Aufgaben erneut prüfen und anschließend Schnittstellen-, End-to-End- und Regressionstests ausführen.“

Im orchestrierten Modus wird der Treiber angewiesen, „jedem Blatt nur den gemeinsamen Vertrag, seine genaue Zuständigkeit und Abhängigkeiten sowie sein eigenes Ledger zu geben“ und „keine unabhängigen Historien anderer Blätter offenzulegen“. Jedes Ledger eines Blatts legt die Pfade fest, die es schreiben darf. Diese OWNS Pfade dürfen sich nicht mit Pfaden anderer Blätter überschneiden, die gleichzeitig gestartet wurden. Wenn ein Subagent zurückkehrt, muss der Treiber „die ausführbaren Prüfungen des zurückgegebenen Blatts erneut ausführen, einschließlich bereits geprüfter Prüfungen“, denn --status allein ist keine erneute Verifizierung. Ein Blatt, dessen Kontrollkästchen ohne echte Nachweise aktiviert wurden, besteht diese erneute Prüfung nicht.

Für die Orchestrierung gibt es eine Untergrenze. Die Orchestrierungsreferenz sagt: „Arbeiten Sie allein weiter, wenn ein fokussierter Kontext die Aufgabe implementieren und verifizieren kann, ohne unabhängige Ergebnisse zu verbergen.“ Jeder Subagent muss sein Verständnis der Aufgabe von Grund auf neu aufbauen. Bei einer kleinen Aufgabe kostet diese Vorbereitung daher mehr, als die zusätzliche Aufmerksamkeit einbringt.

Wie installieren Sie den unlazy-Skill?

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

npx skills add Leonxlnx/unlazy

Fügen Sie -g für eine Installation auf Benutzerebene oder --all für alle von der CLI erkannten Agents hinzu. Dieser Befehl installiert den aktuellen Stand von main. Es gibt kein getaggtes Release. Die README empfiehlt daher, bei Bedarf einen exakten Commit zu pinnen, wenn sich die Installation danach nicht unbemerkt ändern soll.

Bei einer 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 angekommen ist:

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

Die ausgegebene Pfadangabe zeigt, dass sich die Datei auf dem Datenträger befindet. No such file or directory bedeutet, dass der Klon an einem anderen Ort erstellt wurde. Das passiert meist, wenn das skills-Verzeichnis nicht unter dem von Ihnen angenommenen Namen existierte und git ein neues Verzeichnis angelegt hat. Verlassen Sie sich auch nicht allein auf die Aussage des Agents. Wenn ein Agent meldet, dass der Skill installiert ist, wurde die Datei dadurch noch nicht nachgewiesen. Der Checker und der optionale Hook benötigen Node 16 oder neuer. Sie verwenden keine Runtime-Pakete von Drittanbietern.

Am 2026-10-11 dokumentiert die README zwei Harnesses: Claude Code, bei dem Sie den Skill als /unlazy aufrufen, und Codex CLI, bei dem der Aufruf $unlazy lautet. Für Harnesses ohne Skill-Loader ist dort kein Verfahren dokumentiert. Das Einfügen von SKILL.md in die Regeldatei eines anderen Tools ist daher ungetestet. Wenn Sie wissen möchten, was dafür sorgt, dass eine SKILL.md überhaupt zuverlässig geladen wird, behandelt eigenen Agent-Skill schreiben das Frontmatter und den Abgleich der Beschreibung, die darüber entscheiden, ob der Skill ausgelöst wird.

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

Nein. Hier ist eine genaue Unterscheidung wichtig. Alles Bisherige besteht aus 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 Turn zu beenden. Dieser Hook prüft das Ledger und den Dispatch-Status der aktuellen Sitzung. Solange Gates nicht erfüllt sind, verhindert er das Beenden. Der Turn kann daher nicht mit einer ungeprüften Checkbox enden. Der Hook führt die Prüfungen nicht selbst aus und nimmt keine eigenen Modellaufrufe vor. Kostenlos ist er dennoch nicht. In der Referenz zur Token-Nutzung steht: „A block causes another agent continuation, which does consume model work.“ Eine Beschreibung des allgemeinen Mechanismus und der weiteren Ereignisse, an die Sie Hooks anhängen können, finden Sie unter wie Claude-Code-Hooks während eines Turns ausgelöst werden. Die README fordert Sie auf, den Hook nur mit Zustimmung des Benutzers zu installieren. Außerdem sollen .claude/settings.local.json, .unlazy/ und .unlazy-hook-state.json in Ihren Ignore-Regeln verbleiben.

Der Hook verfügt über eine Notabschaltung. Das ist wichtiger, als es zunächst klingt. Wenn der Agent bei sechs aufeinanderfolgenden blockierten Stop-Versuchen keinen Fortschritt bei den Gates erzielt, lässt der Hook ihn weiterlaufen, statt ihn festzusetzen. Änderungen, die ausschließlich Metadaten betreffen, setzen diesen Zähler nicht zurück. Eine Zeile mit ABANDON: <gate> <reason> ermöglicht ebenfalls das Beenden der Sitzung, allerdings als sichtbare Übergabe und nicht als erfolgreiche Prüfung. Das aufgegebene Gate wird als nicht erfolgreiches Ergebnis gemeldet, nicht als abgeschlossene Arbeit. Ohne diese beiden Auswege würde ein Gate, das in Ihrer Umgebung nicht erfüllbar ist, so lange Tokens verbrauchen, bis Sie die Sitzung selbst beenden.

In Codex oder einem anderen Harness kann install-hooks.mjs nirgendwo installiert werden, weil es ausschließlich Claude-Einstellungsdateien schreibt. Sie erhalten weiterhin die Gates-Datei und die ausführbaren Prüfungen. Es gibt jedoch keine strukturelle Sperre, die das Modell daran hindert, den Turn vorzeitig zu beenden. Dort ist die Gates-Datei ein Dokument, das Sie lesen müssen.

unlazy oder ponytail: Welche Variante brauchen Sie?

Diese beiden Skills waren in derselben Saison im Trend und wirken sich in entgegengesetzter Richtung auf den Umfang aus. Deshalb lassen sie sich leicht verwechseln.

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

Wählen Sie den Skill daher nach dem tatsächlichen Fehlerbild. Wenn Ihr Agent aus einer kleinen Funktionalität ein Framework macht, benötigen Sie den ponytail-Skill mit seiner Persona eines faulen Senior-Entwicklers. Wenn Ihr Agent den dritten Punkt einer Anfrage mit vier Punkten unerledigt lässt und anschließend Erfolg meldet, benötigen Sie unlazy.

Sie können beide Skills ausführen. Die Reihenfolge ist wichtig. Legen Sie den Umfang zuerst mit der Frage von ponytail fest. Übergeben Sie den vereinbarten Umfang anschließend an die Prüfungen von unlazy. In umgekehrter Reihenfolge erstellen Sie eine Baumstruktur aus Einzelschritten für Arbeiten, die ponytail gelöscht hätte. Anschließend bezahlen Sie den zusätzlichen Aufwand für all diese Arbeiten. Diese Reihenfolge ist meine Empfehlung und keine dokumentierte Integration zwischen den beiden Projekten.

Welche Kosten verursacht die Tiefe bei einem auf einem VPS ausgeführten Agenten?

Der Aufwand wird in Tokens gemessen. Bei einem Agenten auf einem VPS, der Ihren eigenen API-Key verwendet, kosten Tokens Geld. Wie viel zusätzliche Arbeit unlazy verursacht, beantwortet das Projekt inzwischen nicht mehr mit einer Zahl.

Frühere Versionen dieses Leitfadens enthielten anhand eines Vergleichs über sechs Durchläufe berechnete Multiplikatoren für Ausgabe-Tokens und Kosten. Die Autoren haben diese Werte inzwischen zurückgezogen. In references/token-economy.md steht nun, dass die zugrunde liegenden Roh-Prompts, Traces, Ausgaben und Bewertungsdaten im Repository fehlen, „sodass diese Zahlen hier nicht reproduzierbar sind“. Außerdem heißt es dort: „Verwenden Sie sie nicht als Produktgarantien.“ Die Referenz zur Methode geht noch weiter: „Betrachten Sie die Tiefe nicht als arithmetische Zusage über Aufwand oder Tokens.“ Wir haben die Zahlen entfernt, statt Werte zu wiederholen, für die ihre eigenen Autoren nicht mehr einstehen.

Was die Referenz weiterhin zu den Kosten sagt, ist eine Orientierung. Ihre erste Empfehlung lautet: „Verschieben Sie wiederholte, deterministische Prüfungen in Befehle und halten Sie den Orchestrierungskontext klein.“ Im Solo-Modus werden zusätzliche Ausgabe-Tokens innerhalb eines Kontexts verbraucht. Der orchestrierte Modus fügt Kontexte hinzu. Jeder neue Kontext liest den Vertrag und sein eigenes Ledger, bevor er etwas Nützliches ausführt. Die Referenz warnt in beide Richtungen: „Orchestrieren Sie keine Aufgabe, die eine einzelne fokussierte Sitzung sauber implementieren und prüfen kann.“ Sie warnt außerdem davor, einen gesamten Build nur zur Vermeidung des Subagent-Aufwands in einem Kontext zu halten, wenn die Blätter und Verträge klar sind.

Daraus ergeben sich vier Einstellungen:

• Wählen Sie die kleinste Tiefe, deren Blätter echte Arbeitseinheiten sind, und beenden Sie es dann. Nicht benötigte Tiefe verursacht nicht benötigte Kosten.
• Bleiben Sie im Solo-Modus, wenn eine fokussierte Sitzung die Aufgabe erstellen und prüfen kann. Dort kostet die Einrichtung eines Subagents mehr, als der neue Kontext einspart.
• Installieren Sie den Stop-Hook, wenn Sie Claude Code verwenden. Der Hook führt selbst keine Modellaufrufe aus. Jede Blockierung schickt den Agenten jedoch zurück an die Arbeit, und diese Arbeit wird abgerechnet.
• Legen Sie auf Kontoebene ein hartes Ausgabenlimit fest, bevor Sie etwas Längeres starten.

Der letzte Punkt ist der entscheidende. Eine Fähigkeit, die frühe Abbrüche bewusst ablehnt, arbeitet ihrem Design entsprechend weiter. Budgets und Benachrichtigungen sind eine separate Aufgabe und nicht Teil des Promptings. Die Kosten eines Agenten auf einem VPS unter Kontrolle halten behandelt die Begrenzungen, die Sie zuerst einrichten sollten.

Was die Autoren gemessen haben und was daraus folgt

Das Repository veröffentlichte früher einen eigenen Test. Das kommt seltener vor, als es sollte. Inzwischen haben die Autoren diesen Test zurückgezogen. Das kommt noch seltener vor. In der README steht jetzt nur noch, dass „frühere README-Versionen auch einen internen Vergleich mit sechs Durchläufen angeführt haben“ und dass „die Rohartefakte, die zur Reproduktion dieser exakten Verhältnisse und Anzahlen erforderlich sind, nicht in diesem Repository enthalten sind“. Die Empfehlung lautet: „Behandeln Sie die Ergebnisse als historische Designgrundlage, nicht als Benchmark-Garantie.“

Der Aufbau ist in research/validation-protocol.md erhalten: zwei Build-Aufgaben, jeweils drei Bedingungen (kein Skill, Baum 3, Baum 6) sowie für jeden Durchlauf ein neues Verzeichnis und eine neue Sitzung. Das Protokoll bezeichnet den Test als „vom Maintainer durchgeführten explorativen Vergleich“. Es weist darauf hin, dass die daraus ermittelten Tokenverhältnisse, die selbst gefundenen Fehler, die Live-Fehler und die Fehler bei den Berichtszahlen anhand des Repositorys weder reproduziert noch geprüft werden können. Außerdem darf der Vergleich nicht als Beleg dafür beschrieben werden, dass unlazy eine bestimmte Verbesserung oder einen bestimmten Kostenmultiplikator verursacht. Frühere Versionen dieses Leitfadens stellten die Anzahlen pro Durchlauf aus diesem Test in Diagrammen dar. Nach dem Rückzug durch die Autoren haben wir diese Angaben entfernt.

Eine Design-Erkenntnis hat die Zahlen überdauert. Die Regel, „jede Zahl und jede Aussage zum Abschluss unmittelbar vor der Berichterstellung erneut zu messen“, steht weiterhin in SKILL.md. Die Vorlage für die Gates warnt davor, eine vorgegebene Zahl als eigenen Nachweis in EXPECT zu kopieren. Eine selbstsichere Zusammenfassung auf Basis eines fehlgeschlagenen Builds ist genau das, worauf die Gates abzielen.

Nun zu den Grenzen. Am 2026-10-11 gibt es kein veröffentlichtes Ergebnis mehr, das bewertet werden könnte, sondern nur noch die Methode und ein Protokoll für eine ordnungsgemäße Wiederholung. Testen Sie es stattdessen mit 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 einem von Ihnen selbst erneut ausführbaren Nachweis geschlossen wurden. Diese Anzahl ist die einzige Zahl in diesem Bereich, die Ihnen gehört.

FAQ

Was ist der Depth Tree im Skill unlazy?

Der Depth Tree ist eine Dekompositionsmethode. Eine Aufgabe wird nur an echten Grenzen zwischen Domänen, Komponenten oder Prüfungen aufgeteilt. Layer 1 ist die angeforderte Aufgabe. Jedes Blatt ist ein zusammenhängendes Deliverable mit eigenen Gates. Kleine benachbarte Blätter werden zusammengeführt. Ein Blatt, das mehrere unabhängige Ergebnisse verbirgt, wird erneut aufgeteilt. Jede Ebene oberhalb der Blätter integriert und prüft: Sie prüft die untergeordneten Elemente erneut und führt anschließend Schnittstellen-, End-to-End- und Regressionstests aus. Die Tiefe wählen Sie beim Aufruf, zum Beispiel tree 5. Wenn keine Tiefe angegeben ist, wählt der Skill den kleinsten Baum, der jedes unabhängige Deliverable und jeden Integrationspunkt sichtbar macht.

Funktioniert der Skill unlazy außerhalb von Claude Code?

Teilweise. Der Skill ist einfaches Markdown, und die README dokumentiert Codex CLI neben Claude Code. Daher funktionieren der Depth Tree, die Gates-Datei, die ausführbaren Prüfungen und die vier Durchläufe pro Blatt auch dort. Die aktuelle Dokumentation behandelt keine anderen Harnesses. Die harte Durchsetzung ist jedoch anders. 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. Anderswo verhindert nichts auf struktureller Ebene, dass das Modell seinen Durchlauf vorzeitig beendet. Sie müssen daher selbst die Gates-Datei lesen und sie erneut übergeben.

Wie stark erhöht der Skill unlazy meine Tokenkosten?

Heute kann niemand eine verlässliche Zahl nennen. Die früheren Tokenverhältnisse der Autoren stammen aus sechs Durchläufen, die sich nicht reproduzieren lassen. In der aktuellen Dokumentation steht, dass Sie diese Werte nicht als Produktgarantien verwenden und die Tiefe nicht als arithmetische Zusage für Aufwand oder Token behandeln sollen. Die Richtung ist dennoch klar. Der Solo-Modus fügt innerhalb eines Kontexts zusätzliche Ausgabe hinzu. Der orchestrierte Modus erzeugt pro Blatt einen neuen Kontext, der vor der Arbeit den Vertrag und sein Ledger liest. Der Stop-Hook führt selbst keine Modellaufrufe aus. Jede Blockierung schickt den Agenten jedoch zurück an die Arbeit. Messen Sie die Kosten für Ihre eigene Aufgabe anhand Ihrer eigenen Abrechnung.

Sollte ich unlazy oder ponytail verwenden?

Richten Sie den Skill nach dem vorliegenden Problem aus. ponytail ist für einen Agenten gedacht, der zu viel schreibt. Er übernimmt die Rolle eines Senior-Entwicklers, der fragt, ob der Code überhaupt benötigt wird, und zuerst zur Standardbibliothek greift. unlazy ist für einen Agenten gedacht, der zu wenig von Ihrer Anforderung umsetzt. Der Skill erzwingt die Dekomposition und verweigert das Schließen eines Gates ohne Nachweis. Wenn Sie beide verwenden möchten, legen Sie den Umfang zuerst mit ponytail fest und übergeben Sie ihn anschließend an unlazy. So zahlen Sie keinen zusätzlichen Aufwand für Arbeit, die zuvor hätte entfernt werden sollen.

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

Prüfen Sie vier Dinge. Stellen Sie erstens mit ls ~/.claude/skills/unlazy/SKILL.md sicher, dass der Skill auf dem Datenträger vorhanden ist. Ein Clone in ein Verzeichnis, das zuvor nicht vorhanden war, ist die häufigste Ursache. Stellen Sie zweitens sicher, dass vor Beginn der Arbeit eine Gates-Datei geschrieben wurde. Der Hook scannt das Ledger der Sitzung. Ein fehlendes GATES.md liefert ihm nichts, was er blockieren kann. Prüfen Sie drittens, wo der Hook installiert wurde: Der einfache Aufruf install-hooks.mjs schreibt nur in das settings.local.json dieses Projekts. Für ein anderes Projekt benötigen Sie --global. Denken Sie viertens daran, dass die Ausstiegssperre wie vorgesehen funktioniert. Nach sechs aufeinanderfolgenden blockierten Stopps ohne Fortschritt bei einem Gate wird der Agent freigegeben. Eine Zeile mit ABANDON: <gate> <reason> beendet den Versuch absichtlich als sichtbare Übergabe, die keinen Erfolg darstellt.