unlazy v2 Moves Agent Discipline Out of the Prompt and Into a Gates File

The anti-laziness skill argues that prose cannot enforce prose, so it puts acceptance criteria in a file, runs them as shell commands, and blocks the agent from stopping while any box is unchecked. Here is what holds up and what does not.

There is one sentence in the unlazy README that justifies the entire rewrite, and it is worth reading twice before you look at any of the code.

"A model that under-executes instructions also under-executes the instruction not to under-execute."

Version 1 of this skill was a single markdown file that told the agent to work harder. Version 2 throws that approach out and replaces it with something you can point at. Acceptance criteria live in a file. Each criterion carries a shell command and an expected string. A script runs the commands and flips the checkbox only when the output matches. On Claude Code, a hook mechanically blocks the agent from ending its turn while any box is still open.

The repo's summary of the shift: "You do not promise you are done. You prove it against a ledger."

That is a real idea, and it is worth taking seriously. It is also worth applying to the repo itself, which is where this gets interesting.

What a gate actually looks like

The format is small enough to fit in a paragraph. A gates file holds entries like this:

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

gate-check.mjs runs each CHECK command, compares output against EXPECT, ticks the box only on a match, and pastes the deciding output lines into the EVIDENCE field. A box that is checked while its evidence still says pending counts as unmet. The README puts the rule bluntly: a checkbox is a claim, evidence is the proof.

The enforcement stack has five layers, each catching what the layer above misses. The skill file itself is the weakest and works in any agent. Gates files keep the intentions you wrote at minute two sharp at minute ninety. Runnable checks let a command decide instead of a feeling. In orchestrated mode the parent re-runs each leaf's checks, because self-certification counts for nothing. The Stop hook is the floor.

The hook deserves a note because it is the only piece that is genuinely mechanical rather than persuasive. It is a file scan, so it costs zero tokens per check. It has a loop guard: if the agent makes no gate progress across six consecutive blocked stops, the hook releases it with a warning rather than trapping it, and an ABANDON: <gate> <reason> line is always honored as an honest exit. Someone thought about the failure mode where an agent gets stuck in a wall of its own making, which is more care than most hooks get.

Everything is MIT licensed, zero-dependency Node 16 or later, and installs with npx skills add Leonxlnx/unlazy. The gates and scripts work anywhere. Hard enforcement is Claude Code only.

The test that motivated the rewrite

The README does not just assert that instructions are weak. It reports a controlled test: two build-from-scratch tasks (a marketing site and a three.js solar system), three conditions each (no skill, tree 3, tree 6), one fresh folder and fresh session per run, same model, same prompt body, with every output code-reviewed by independent agents and live-tested in a browser.

Five findings, summarized in the repo's own words:

The baseline already shipped zero placeholders and zero console errors, so the banned-word lists that v1 leaned on were fighting a problem the model had already solved. The skill raised effort somewhere between 1.6x and 3.9x and caught four to ten self-found defects before delivery. Tree 6 cost about 1.0 to 1.5 times tree 3, nowhere near the 8x that the original 2^(N-1) arithmetic promised, so depth stopped being an effort multiplier and became plain decomposition. The only hard live failure was a baseline build whose report claimed the case was handled.

And the finding that produced the report audit rule: every skill run's final report contained one to three wrong numbers, while the baselines had zero.

Sit with that last one. The failure that survived into the frontier-model era is not stubs or TODO comments. Those are gone. What remains is an agent that finishes, reports confidently, and gets its own numbers wrong. That is a much harder thing to catch by reading, and it is exactly what a ledger with pasted evidence is built to stop.

Where the repo fails its own test

Here is the part I did not expect to write.

The README asks you to accept a set of headline numbers. Effort raised 1.6 to 3.9x. Four to ten defects caught. One to three wrong numbers per report. Those are the load-bearing claims for adopting the tool.

The repository contains SKILL.md, a references/ directory, scripts/, templates/, a changelog, a contributing guide, a license and the README. There are no run logs, no captured outputs, no test harness, no artifacts. The six runs that produced those ratios are not in the repo, so nobody can re-derive them. The project's own report audit rule says every number in a final report gets re-measured at report time or labeled unverified. Its README is a final report, and by its own standard those numbers sit in the unverified column.

The changelog adds a wrinkle. Version 1.0.0 and version 2.0.0 are both dated 2026-08-10. The controlled test of v1 and the rewrite that replaced it happened inside a single day. That does not make the findings wrong. It does mean this is a designer's bench test of his own method, run the day he shipped it, not field evidence from other people's projects.

The research list is where I would push hardest. It is long and it looks solid, and one citation does not say what the surrounding argument implies. The Quantifying Laziness paper does find widespread compliance failures on multi-part instructions, which is quoted accurately. That same paper also reports limited evidence of decoding suboptimality and, in its own words, surprising robustness against context degradation across a 200-turn conversation test, with models holding key facts far better than expected. It ran on a GPT-4 variant and DeepSeek. The README cites it in a section that builds toward long-context degradation and context anxiety, and the paper's context finding points the other way.

Other citations hold up cleanly. SlopCodeBench does report that the best of fifteen coding agents passes 14.8 percent of checkpoints across 36 problems and 196 checkpoints, with agent code 2.3x more verbose and 2.0x more eroded than 473 open-source Python repositories. That one is quoted correctly and it is the strongest evidence in the list.

One more small thing that says something larger. In a single research session, GitHub served me three different star counts for this repository: 12 on one page load, 730 on another, and 815 on a third, with forks reading 0, 41 and 54. The briefing I started from reported roughly 1.2k. Every one of those was a live page. The repo is moving fast enough that its own popularity is an unverifiable number, which is a small joke at the project's expense and also precisely the class of problem the gate ledger exists to solve.

Putting this into practice

You can adopt the useful part of unlazy in twenty minutes without installing anything.

Write your acceptance criteria before the agent starts working. Open a file called GATES.md in the project root. Write three to five checkboxes describing what "done" means in terms someone else could verify. Do this while the task is still clear in your head, which is minute two, not minute ninety.

Give every gate a command. If a criterion has no shell command that can decide it, the criterion is too vague. Rewrite it until it does. This single constraint improves how you specify work even when no agent is involved.

Demand pasted evidence, not a summary. Ask for the deciding output lines under each gate. A summary of a passing test is where the wrong numbers live.

Try the skill on a real task. npx skills add Leonxlnx/unlazy then /unlazy tree 3 <your task>. Tree 2 to 3 for a feature or a bug hunt. Stay solo unless the job is genuinely half an hour or more of work.

Install the hook only after the gates feel right. node <path-to-skill>/scripts/install-hooks.mjs scopes it to the current project. Add .unlazy-hook-state.json to your .gitignore. Blocking an agent from stopping against gates you wrote carelessly is a worse experience than no gates at all.

Then run the project's own rule against the project. Count how many of your gates the agent failed without saying so, and how many numbers in its final report you can reproduce. That is your data, on your work, and it is worth more than anyone's README.

Honest limits

The Stop hook, the only hard enforcement here, is Claude Code exclusive. On Codex, Cursor or anything else this is discipline in a markdown file, which is the layer the project itself calls the weakest.

The cost is not free and the README is straight about it. Solo mode runs roughly 1.5 to 4 times baseline output, plus a few hundred tokens of overhead. Orchestrated mode multiplies with leaf count by design. Below about half an hour of work, this buys you nothing but a longer bill.

Gates are only as honest as the person writing the CHECK commands. An agent that writes its own gates can write easy ones. The orchestrated mode's parent re-verification exists to catch that, and in solo mode the only reviewer is you.

The whole approach assumes your work has a verifiable surface. Building software qualifies. Writing, research and design mostly do not, and forcing a CHECK: line onto a judgment call produces theater rather than proof.

What to take from it

Ignore the star count and the effort multipliers. The idea worth keeping is that a completion claim and a completion proof are different objects, and that only one of them survives contact with a long session.

Put your acceptance criteria in a file before work starts. Attach a command to each one. Make the agent paste evidence. Then apply exactly that standard to every tool that tells you how well it works, starting with this one.

Sources: Leonxlnx/unlazy on GitHub (README and CHANGELOG, retrieved August 23, 2026); Quantifying Laziness, Decoding Suboptimality, and Context Degradation in LLMs, arXiv 2512.20662; SlopCodeBench, arXiv 2603.24755.