The Unlazy Skill: How to Stop AI Agents From Lying About Being Done

There's a fundamental problem with AI agents: they never take ownership of a task, which is why you can't trust the output without reviewing it yourself.

There's a fundamental problem with AI models: they never take ownership of a task, which is why you can't trust their output without reviewing it yourself. GitHub's number one trending author, the same person behind the popular design taste skill, built a skill called Unlazy that fixes exactly this. The idea is simple: it doesn't tell you the agent is done, it proves it. We ran it, hit a serious flaw in how slow it was, and fixed that too.

We build software, and agent laziness is a problem we hit constantly. It shows up no matter which model you use, even Opus and GPT 5.6. It's just easier to spot on smaller models, where the limitations surface faster. Unlazy is built to fix it, and the way it works is genuinely clever: instead of a summary claiming the work is complete, it checks the work against a ledger where every item has to carry proof it's actually done. It works with Claude Code, Codex, and the other popular agents. Here's why agents get lazy, how the skill fixes it, the flaw we found, and the change we made.

Why agents get lazy in the first place

On a fresh context window you won't notice it. There's barely anything in there, so the model focuses well on the task. It gets worse as the context fills up. These models have no built-in memory, so they don't actually know what happened in your earlier messages. The way they know is that the agent sends all the previous messages along with your new prompt. As that pile grows, there's more for the model to pay attention to at once, so it focuses less clearly on each part of the task and starts slacking off.

That laziness shows up two ways.

It tells you it's done when it isn't. Ask Claude Code to work through many files and it often opens a few, then reports it went through everything. A model that stops early with obviously unfinished work is fine. The problem is when it stops early and tells you it finished, because you don't know it's incomplete until you check. Build on top of that and you hit problems later.

It shrinks the job without telling you. Ask for something with five parts, one of them hard, and it builds the four easy ones and skips the hard one, and the summary never mentions anything's missing.

Why the older fixes fall short

None of this is new, and people have built fixes for a long time. But each has a limit.

• The Ralph loop keeps resending the same prompt until an indicator in the output says it's done. But that finish line is just text the agent writes, and plenty of tasks can't be judged by a word. There's no single token that proves a feature is built properly.
• Claude's goal command uses a smaller model as a judge that reads the conversation to decide if the work is finished. So it judges by what the conversation says, not the work itself, and it can drift from what you needed.
• Our own loops used real checks in a task list, but the agent itself graded them, so it was still the agent deciding whether it was done.

All of these work well on a fresh context window and start to falter once you're deep into real work, which is exactly when you need them to hold.

How Unlazy works: the tree

When you give the skill a large task, it doesn't start working. It breaks the task into smaller tasks, then breaks each of those into smaller tasks again, branching out, which is why it's called a tree. Once it stops splitting, every small task at the end gets handed to its own sub-agent.

You control how many times it splits. In your prompt you name the skill and give it a number, which is the depth of the tree. Say five and it breaks the task down five times and no further. Give no number and it picks the smallest depth that fits.

The reason goes straight back to the attention problem. When work is broken up like this, each task has one clear goal, and the agent working it isn't carrying the rest of the job around. But tasks can't be too small either. The rule is each should be worth at least 10 minutes of real work, a proper piece an agent can pick up and finish on its own. Set the number too high and the tasks come out smaller than that, and the skill lowers the split to the default of three.

That number also decides how the work runs. Three or under is solo mode, the default, where everything stays in one session and the same agent works through all of it. Four and up switches to orchestrated mode, where it writes much more down: a plan file with the whole breakdown, and a separate checklist for every task.

Takeaway: Unlazy splits a big task into a tree of 10-minute pieces so each agent carries one clear goal instead of the whole job. You set the depth, and it corrects you if you overshoot.

The gates file: proof, not promises

Why write it to a file at all? Because the previous version of this skill tried to fix laziness by telling the agent to be thorough, and an instruction is the first thing to get lost in a long session, which is the exact problem it was fixing. So this version stopped asking and started putting it in a file before any work begins.

That file is the gates file, the ledger. Every item in it is a gate: a checkbox with an outcome written next to it, one thing that has to be true before the task counts as done. Under each outcome are three lines: the command that proves the outcome, the exact words that command has to return, and the evidence, which starts out as "pending."

The skill comes with a checker. Run it and it goes down the file and runs every command itself. If the answer contains the words the gate expected, it ticks the box and replaces "pending" with the part of the answer that decided it. That evidence line is what closes the hole in every older fix. A ticked box that still says "pending" underneath means the agent ticked it itself, which is just the agent claiming it's done all over again, so it counts as unmet. The skill treats that as worse than an empty box, because an empty box is at least honest about where the work got to.

The same rule keeps big runs honest. In orchestrated mode it hands one task to a fresh agent that only gets the plan and its own gates file, nothing about the rest of the job. When that agent says it's finished, the main one doesn't take its word for it and runs that task's checks again itself, and only then writes a line into the plan file and hands out the next task. There's also an honest way out: if a task turns out to be impossible, the agent writes a line giving up on that gate by name with the reason, and that goes into your final report. So Unlazy is a whole system, and at no point does the agent get to decide whether the work is done.

Takeaway: A gate isn't ticked because the agent says so. It's ticked because a command ran and returned the exact expected output, with the evidence written back into the file.

Installing it

Go to the GitHub page, find the install section, copy the command (link in the description), open the terminal inside your project, and run it. The installer asks which agent you're using. On Codex you don't change anything, because it installs into the agents folder Codex already reads. On Claude Code you select it from the menu, and you can pick several agents at once. Then it asks the scope: only this project, or everything you build. We chose project scope to test it on one project first. Take the recommended options and it's done.

Open the project in VS Code and you'll see two folders, agents and .claude. They aren't two copies. The skill lives in the agents folder, and .claude is just a shortcut so Claude Code recognizes it without duplicates. The skill file inside holds all the guidance for the agent.

The flaw we found, and the fix

Run the skill exactly as it ships and it takes a very long time to build anything meaningful. We tested it on an app, the session ran three to four hours straight, and when we checked, there was a login page and nothing else.

Going through the skill, the problem was in its instructions. Both Claude Code and Codex can run several agents at the same time, each working in parallel on a different task. But the skill handed out one task, waited for it to complete, then handed out the next. So even though it was running agents, it wasn't using their parallel capability at all, and that's where the hours went.

So we changed the skill itself to actually use the fact that these tools can run several agents at once. (You can copy the prompt we used from the video if you want to make the change yourself.) To run it, you type the skill name, the depth of the tree, then everything you want built. Building the demo app from scratch, we used five, but pick the number by the size of your task. For a single feature rather than a whole app, two or three is enough, and if you pick higher than needed it lowers the depth for you.

Before it builds anything, it writes the plan.md and gates.md files. In plan.md it also notes which task works on which file, so two agents running at once don't overwrite each other. Then it lays the foundation and hands work out to the agents all running at the same time. With the fix in, 10 agents were working at once, each on a different part. That run went for nearly two hours, and we ended with the first version of the demo app running, every feature working as we wanted.

If you're building at this scale, pair it with a model router skill, which sends each task to the right model, so simple mechanical work goes to a cheaper model and the hard parts go to the strong one, which keeps you from hitting your limit fast.

Takeaway: Unlazy's proof system is excellent, but out of the box it runs tasks one at a time. Rewrite it to run agents in parallel and a build that took hours for a login page finishes the whole app in about two.

FAQ

What does Unlazy actually fix? Agents that claim a task is done when it isn't, or that quietly skip the hard part. It proves each piece of work with a checklist of gates instead of trusting the agent's summary.

What is a gate? One thing that has to be true before a task counts as done, with a command that proves it, the exact output that command must return, and an evidence line. A checker runs the commands and fills in the evidence.

Why is a ticked box with "pending" treated as worse than an empty box? Because it means the agent ticked it without proof, which is the exact lie the skill exists to stop. An empty box is at least honest about where the work got to.

What's the depth number? How many times the task is split into a tree of subtasks. Higher for a whole app, lower for a single feature. If you overshoot, the skill lowers it automatically so tasks stay worth at least 10 minutes of work.

Why was it so slow, and how do you fix it? It handed out tasks one at a time instead of using the agents' ability to run in parallel. Rewriting the skill to run them at once cut a multi-hour build down to about two, with 10 agents working together.

The takeaway

Agent laziness is real on every model, and it gets worse the deeper you are into a session, which is exactly when the old fixes stop holding. Unlazy solves it by never letting the agent be the judge: every task carries a gate that a command has to prove, with the evidence written back into a file. The one catch is speed, and that's fixable. Make it run agents in parallel and you get an honest, self-proving build in a fraction of the time.

The parallelized version of the Unlazy skill we built lives inside AI Labs Pro.