This Skill Treats Agent 'Done' Reports as Untrusted Data

The Laziness You Cannot See

For all the talk of reasoning models and million-token context windows, a quieter failure mode has taken hold in AI coding agents: they stop too soon. Not because they crash, but because they decide they are finished. Recent research has given this behavior names—premature truncation, underthinking, context anxiety—and found it even in frontier models. One study defines LLM laziness as partial compliance with multi-part requests and premature truncation of responses. Another notes that reasoning models abandon promising lines of thought early, a pathology called underthinking. On long-horizon coding benchmarks, agents degrade over iterative work, with verbosity and code erosion outpacing human repositories. Some models even underestimate their remaining context window and wrap up early, a behavior now labeled context anxiety.

The unlazy project enters this landscape with a specific observation: the visible symptoms of laziness are already disappearing. Placeholders and console errors are largely solved by baseline frontier models. The remaining failures are invisible—a live build that breaks but whose report claims success, or a final summary that contains confidently wrong numbers. These are not hallucinations in the traditional sense; they are premature declarations of victory. Unlazy treats the “done” report itself as untrusted data and builds a structure to replace it.

Prose Cannot Enforce Prose

The project’s first version was a simpler plea: ask the model to work harder. The author tested this instruction-only approach against two build-from-scratch tasks under controlled conditions. The skill raised agent effort by a factor of 1.6 to 3.9 and caught four to ten self-found defects before delivery. Yet the deeper finding was that instructions alone hit a ceiling. A model inclined to under-execute will also under-execute the instruction not to under-execute. Prose, the project concluded, cannot enforce prose.

Version two keeps the depth-tree decomposition but moves enforcement into structure. The insight is layered: discipline lives in the skill file, intentions sharpen in per-task gate files, verification becomes a runnable command, parent agents re-run checks rather than trust self-certification, and an optional hook mechanically blocks the agent from ending its turn while gates remain unmet. It is a hierarchy where each layer catches what the one above misses. Skills directories have begun listing it alongside other agent-side tools, and video overviews highlight its security-conscious approval model and re-verification workflow, signaling that practitioners are looking for exactly this kind of scaffolding.

The Ledger, the Gate, and the Tree

At the center of the method is a file called GATES.md, written before implementation begins. Each gate states one observable outcome and, where possible, a runnable check command and an expect string that must appear in the output. A separate script runs these checks, flips the checkbox only when the expectation matches, and records the deciding output lines as evidence. A checked box still counts as unmet if its evidence reads pending. Done is not a feeling; it is a ledger whose every line is full.

This design carries an unusual security posture for a productivity tool. As detailed in its published skill specification, the tool treats inherited gate files, command output, and any text they reference as untrusted data. Before executing an inherited ledger, the agent parses it without running anything and reads every command. Approvals bind to the exact command, working directory, shell, timeout, platform, and inherited path; change any bound input and the approval voids. The tool will not silently remove an impossible gate, either—abandonment requires a non-empty reason and surfaces as a required handoff, not a stealth deletion.

For larger builds, the Depth Tree method decomposes work into leaves and branches. A leaf is a real unit of work—ten minutes or more, one deliverable, one gates file. The user selects the depth: shallow for a feature or bug hunt, deep for a subsystem or whole project built leaf by leaf with fresh-context subagents. Before any leaf starts, a plan file fixes interfaces and file ownership. Branches carry integration gates to catch the case where dozens of locally perfect leaves still yield a broken product. In orchestrated mode, each leaf can run as a fresh subagent, trading context-window continuity for the clarity of a short horizon. The optional Stop hook, available only in Claude Code, performs a millisecond file scan to block turn completion while the ledger is open. After six consecutive blocked stops with no gate progress, the hook releases the agent with a warning, an anti-deadlock measure that acknowledges even mechanical enforcement has limits.

Effort Is Steerable, but Not Free

The project is refreshingly direct about costs. Solo mode, using a single gates file without the hook, adds a few hundred tokens of overhead and roughly 1.5 to 4 times the baseline output on tasks the model would otherwise treat lightly. That multiple buys committed design, robustness sweeps, and pre-delivery bug hunts. Orchestrated mode multiplies cost with leaf count, deliberately, and the advice is blunt: below roughly half an hour of work, stay solo.

Task decomposition is not new; enterprise frameworks have long broken complex objectives into smaller units to improve auditability and reduce error propagation. What unlazy adds is a user-land, file-based enforcement layer that requires no orchestration platform or model retraining. Yet there are savings hidden in the structure. Every check line replaces thousands of tokens of the model re-reading its own work with a free subprocess. This mirrors a broader research trend: systematic decomposition of complex LLM tasks, guided by formal complexity measures rather than heuristics, has been shown to improve accuracy by nine to forty percentage points on combinatorial and database-querying benchmarks. Unlazy applies a similar philosophy in user space, trading model introspection for executable oracles. The idea that effort is steerable through structure rather than pleading also aligns with training-side findings that verifiable rewards and reasoning traces can unlock complex problem-solving—though unlazy operates entirely at the agent harness layer.

The Honest Limits

What makes the repository credible is what it refuses to claim. Its own controlled test found that every skill run’s final report still contained one to three wrong numbers, while baselines had zero. Hence the report audit rule: re-measure every number at report time. The Stop hook is Claude Code only. Hard enforcement is optional everywhere else; the rest is plain markdown and zero-dependency Node scripts that run on anything capable of reading a skill file. The author notes that the banned-list of lazy behaviors was fighting a solved problem—visible placeholders are gone—so v2 aims at what actually failed.

This honesty places unlazy in a distinct category. It is not a model, a framework, or a platform. It is a discipline encoded into files, a small piece of execution infrastructure that acknowledges the agent is an unreliable narrator about its own progress. In a landscape where much agent tooling promises smoother interaction, unlazy introduces friction by design. The gate must be checked, the evidence must be recorded, and the report must be re-measured. That friction is the point.