Your AI agent lies about finishing. Unlazy makes it prove it.

A 3-to-4-hour nonstop agent session. The final result: a login page. Not one screen more.

That's not a moody model, that's the symptom of a known problem: AI agents are lazy. And an open-source skill just shipped the most solid answer I've seen so far. With one youthful flaw that I also learned to fix.

The real culprit: your context window

Laziness hits every model, including today's most powerful ones (Opus, GPT 5.6). It's just more visible on smaller models, because their limits show fast.

The cause fits in one sentence: these models have no internal memory. When you send a new message, the agent resends the ENTIRE conversation history along with your prompt. That's how it "knows" what happened before.

On the first exchange, the pile is tiny and the model focuses perfectly. By the fiftieth, it must read a whole novel to write one sentence. Its attention dilutes, and that's when the corner-cutting starts.

And this corner-cutting takes exactly two forms:

1. It declares "done" when it isn't. You ask it to review 20 files, it opens 5 and swears it read everything. Stopping early with visibly unfinished work is forgivable. Stopping early while claiming everything is done is where it costs you: build on top without verifying and you're stacking on thin air.

2. It silently shrinks the job. Your request has 5 parts, one of them hard. It delivers the 4 easy ones, skips the hard part, and its final summary never mentions anything missing.

Why the classic fixes hit a ceiling

The problem isn't new and patches have existed for a while. They all share a flaw.

• The Ralph loop resends the same prompt to the agent again and again until an indicator in its output says "finished". But that finish line is just text written by the agent while it works. And many tasks can't be judged by a magic word: no single word proves a feature is properly built.

• Claude's goal command has a second model read the conversation and arbitrate. So it judges what the conversation SAYs, not what the work IS. It drifts.

• Homegrown task-list loops have real checkboxes, but the agent grades itself. The student marks his own paper.

Common point: all of these hold up remarkably well while the context window is fresh. And all of them collapse exactly when you need them, deep into a long session.

Unlazy: don't say you're done, prove it

The Unlazy skill comes from the author of the wildly popular design taste skill (GitHub's number one trending author at the time I'm writing this). Its core idea is one inversion: the agent no longer says it's finished, it PROVES it.

Concretely, when you hand it a large task, it doesn't start working right away. It splits. Then splits each piece again. The task becomes a tree, and you choose the depth by writing it in your prompt: unlazy 5 means five levels of splitting, no further. Without a number, it picks the smallest one that fits.

Two rules frame this decomposition:

• Every leaf of the tree must be worth at least 10 minutes of real work. Big enough to be a proper chunk of the job that one agent can carry alone from start to finish.
• If leaves come out too small, the skill lowers the depth to 3, the default.

And the depth decides the execution mode: 3 or below is solo mode, one session and the same agent chaining everything. 4 or above is orchestrated mode, more on that in a minute.

The gates file: the ledger that changes everything

Why does this skill work where others plateau? Because its first version failed in the most instructive way possible.

V1 merely instructed the agent: be thorough, be exhaustive. Result: an instruction is the FIRST thing that gets lost in a long session. Exactly the problem it claimed to fix.

The new version stopped asking. It writes. Before any work begins, the skill produces a file, the gates file: the ledger I mentioned.

Each entry is called a gate. A checkbox with, next to it, the outcome: ONE thing that must be true for the task to count as done. Under that outcome, three lines:

The skill ships with a checker. When you run it, it walks down the file and executes EVERY command itself. If the output contains the expected words, it ticks the box and replaces "pending" with the output fragment that decided it.

That evidence line plugs the hole in every previous solution. Scoop: a TICKED box whose evidence still reads "pending" doesn't count as met, it counts as UNMET. The agent graded itself; we're back to the usual lie. The skill treats that as WORSE than an empty box, because an empty box is at least honest about where the work actually stands.

And there's a clean emergency exit: if a task turns out impossible, the agent doesn't quietly drop it. It writes a line giving up on THAT gate BY NAME, with the reason, and that line surfaces in the final report. Nowhere in the entire chain does the agent get to decide alone whether the work is done.

Orchestrated mode: fresh agents, one per task

At depth 4 and above, every leaf goes to a BRAND-NEW sub-agent that receives only the plan and ITS OWN gates file. Nothing else about the job. Nearly virgin context window, hence maximum focus, the exact opposite of the original problem.

But when the freshly hired agent comes back claiming completion, the main agent doesn't take its word. It reruns that task's checks itself. Only after validation does it write a line into the plan and hand out the next one.

Even the hierarchy answers to the ledger. That's system design.

Installation, two minutes flat

1. Head to the skill's official GitHub page, install section: copy the command.
2. Open a terminal INSIDE your project and run it.
3. The installer asks which agent: Codex installs natively into the .agents folder, Claude Code gets selected from the menu (you can tick several at once).
4. Scope choice: this project only, or all your future builds. I went with project scope to test on one specific case.
5. Recommended options, and you're installed.

Neat detail: in VS Code you'll see two new folders, .agents and .claude. They are NOT two copies. The skill lives in .agents, and .claude is just a shortcut so Claude Code recognizes it without duplication.

The flaw: it's slow. Very slow.

Tested as-is on an app built from scratch: a 3-to-4-hour straight session, and at the end, a login page. Nothing else.

Digging through the skill's instructions, the cause is crystal clear. Claude Code and Codex alike can run MULTIPLE sub-agents at once, each on a different task. But the skill hands out one task, WAITS for completion, then hands out the next. Single file line. It was running agents, but not using their ability to work in parallel. All those hours went there.

The fix fits in one prompt that modifies the skill itself to exploit concurrent execution. Usage becomes: skill name, depth, then your full request.

• Whole app from scratch: depth 5.
• One isolated feature: 2 or 3 is plenty.
• Depth too high? Automatic lowering, nothing to worry about.

Before writing a single line of code, it first generates plan.md then gates.md. plan.md maps which tasks touch which files, so two simultaneous agents never overwrite each other.

Patched run result: 10 agents in parallel, each on its own chunk. About 2 hours of runtime. At the end, the first version of the app runs, every feature works as intended.

At this scale, pair it with a model router skill: each task goes to the right model, mechanical work to a cheap one, hard parts to the strong one. Your quota limits last far longer.

What this really changes

An agent's laziness was never a willpower problem. It's an attention problem, and you don't fix it by praying, nor by promising.

You fix it with structure: one task per fresh window, and a ledger of executed proofs that nobody, neither the agent nor its orchestrator, can bypass. Trust is no longer declared. It's verified, line by line, in a file.