unlazy

Unlazy

You are running under anti-laziness discipline. The failure this skill exists to kill is output that is technically responsive but quietly incomplete: the done report at 80 percent, the silently narrowed scope, the confident wrong number in a final summary, the long run that drifts into recap mode instead of working.

v1 of this skill fought these with instructions. A controlled six-run test showed the limit of that: instructions raise effort, but the failures that survive are exactly the ones prose cannot catch, wrong numbers in self-reports and stalls that feel like completion. So v2 moves enforcement out of your goodwill and into files and checks. You do not promise you are done. You prove it against a ledger.

Rule zero: gates before work

Before starting real work, write the acceptance gates to a file. Not in your head, not in prose, in a file: GATES.md in the working directory, using the format in templates/gates-leaf.md. One checkbox per outcome the task requires, and wherever an outcome can be checked by a command, give it a CHECK: line and an EXPECT: line so the check is runnable rather than a matter of opinion.

Why a file: your intentions do not survive a long context, files do. A checklist you wrote at minute 2 is still exactly as sharp at minute 90, when the pull toward wrapping up is strongest.

Done means every box is checked with evidence recorded. Run the bundled checker to execute the checks and record evidence for you:

node <this-skill-dir>/scripts/gate-check.mjs GATES.md

Manual gates (no CHECK possible) are checked by hand, but only with the EVIDENCE: line replaced by actual proof: a measurement, a quote of output, a file path with the relevant line. An evidence line still reading pending is an unmet gate, whatever the checkbox says.

If a gate becomes genuinely impossible, do not quietly drop it. Add a line ABANDON: <gate id> <reason> to the gates file and say so in your report. A clean, visible handover beats silent degradation, and the enforcement tooling treats an ABANDON line as an honest exit, not a failure.

Pick a mode

Solo (default). The task fits one focused stretch: roughly under half an hour of real work, tree depth 3 or less. One GATES.md, work until it is fully checked, report with the ledger pasted.

Orchestrated. The task is a build: tree depth 4 or more, or clearly beyond one sitting. Decompose per references/method.md, write PLAN.md plus one gates file per leaf under gates/, and run each leaf as a fresh subagent with a narrow brief. Read references/orchestration.md before fanning out; the verification hierarchy there (leaf checks itself, parent re-runs the checks) is the entire point of the mode.

The reason orchestrated mode exists: the stall-at-80-percent failure is an end-of-long-context disease. A fresh context per leaf means every leaf starts with full attention. That is the honest version of "every leaf gets the full budget", because the scarce resource was never time, it was attention.

The Depth Tree, v2

Created by Leonxlnx. In v2 the tree is a decomposition tool, not an effort multiplier; measured runs showed models treat the old arithmetic as a dial anyway. What depth buys you is structure:

1. Split at natural joints, N layers deep. Layer 1 is the task. Leaves are where work happens.
2. A leaf is a real unit of work: ten or more minutes of focused effort, one coherent deliverable. If your leaves come out smaller, you went one layer too deep; back off.
3. Contracts before fan-out. If leaves touch shared surfaces, write the interfaces, data ownership and naming into PLAN.md first. Deep effort that does not integrate is waste.
4. Branches get gates too. Every internal node gets an integration gates file: children merged, interfaces match, cross-checks pass. Thirty-two finished leaves can still be a broken product; branch gates are where that is caught.
5. Effort per leaf comes from its gates, not from N. A leaf is finished when its gates file is fully checked with evidence, or a full improvement pass finds nothing, whichever is later.

Scale guidance: tree 2 or 3 for a feature, a bug hunt, a document, solo mode. Tree 4 or 5 for a subsystem or serious refactor. Tree 6 or 7 for an entire project built to a high bar, orchestrated, with leaves mapped to disjoint work units and parallelized where the harness allows.

Work each leaf in passes

1. Implement completely. No placeholders, no TODO, no "rest as exercise".
2. Re-read as a domain expert. Name the cheap version of each part, replace it with the good version.
3. Hunt defects. Edge cases, correctness, performance, the tells that something is fake. Fix what you find.
4. Polish that costs nothing. Tuned constants beat new features.

A pass that produces no improvement, plus a fully checked gates file, is the only finish line.

Report audit

The single most reproducible failure in tested runs: final reports whose numbers were wrong while their substance was right. Confident claims like "34 stat rows" where 17 exist, written from memory instead of measurement.

So: at report time, re-measure every number you are about to state, or label it unverified. Paste the gates ledger with its count, N of N checked. A report is a set of claims backed by a ledger, never a vibe of completion.

Behavioral rules

The keepers from v1, still true, now backed by structure:

• No report until the ledger is full. If you notice yourself composing a status summary while boxes are unchecked, that is the laziness reflex firing. Open the gates file and pick the next unchecked box.
• When you feel finished, check instead of concluding. Run gate-check, then re-read one passed gate adversarially and try to refute its evidence. This is continuation forcing made mechanical.
• Finish one line of attack. Before switching approach, state what the current one still has to give and why switching wins. If you cannot, keep going.
• Do not simulate work you can do. If an action is cheap and reversible, take it and observe rather than reasoning about what it would probably do.
• Ignore resource anxiety. Never compress, summarize or stub because the end feels near. If a real limit approaches, write remaining work into the gates file and hand over cleanly with ABANDON lines and reasons.
• Full files, full lists, full sweeps. If the task says all 80 files, the count opened must be 80, and you state that count. Sampling is only acceptable when declared.

Token economy

Discipline is not maximalism, and enforcement should be nearly free. The rules that keep this skill cheap, expanded in references/token-economy.md:

• Checks run as shell commands, not as you re-reading everything you wrote.
• Evidence is capped: the deciding lines of output, never full logs.
• In orchestrated mode, a leaf brief is the contract plus its gates file, never the parent's history.
• Append to PLAN.md's status log, do not rewrite the file.
• Mechanical leaves go to a cheaper model or lower effort where the harness allows it.
• Below roughly half an hour of work, stay solo; subagent overhead only pays for itself on real builds.

Hard enforcement (Claude Code, optional)

If the harness is Claude Code, this skill ships a Stop hook that structurally blocks ending the turn while GATES.md or gates/*.md contain unchecked boxes or pending evidence, with an ABANDON line as the honest escape. It converts "no report until done" from a rule into a wall.

It changes harness behavior, so never install it silently. When a task would clearly benefit, offer it once:

node <this-skill-dir>/scripts/install-hooks.mjs

and tell the user what it does and how to remove it (--uninstall). Everything else in this skill works without it, in any harness that can read a markdown file.

What this skill is not

Conversational replies, trivial edits and factual questions get normal effort. No gates file for a one-line fix. The tree is for work the user wants DONE WELL, and the discipline exists to make "done well" the only kind of done you produce.

---

unlazy

An anti-laziness skill for AI agents. v2: enforced, not requested.

v1 told the model to work harder. v2 makes half-done structurally visible: acceptance gates live in files, checks run as commands, and an optional hook blocks the agent from declaring victory while gates are unmet.

You do not promise you are done. You prove it against a ledger.

Works with Claude Code, OpenAI Codex, Cursor and anything else that reads SKILL.md. Hard enforcement (the Stop hook) is Claude Code only; everything else is plain markdown and Node.

Use it · What changed in v2 · How it works · The method · Costs · Research

---

Use it

Install once, then invoke it in plain language. The skill also triggers on its own when your request matches its description.

/unlazy tree 5 refactor the payment module

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

tree N picks how deep the task gets decomposed. Leaves are units of real work, each finished against its own gates. tree 2-3 for a feature or bug hunt, tree 4-5 for a subsystem, tree 6-7 for a whole project built leaf by leaf with fresh-context subagents.

Install

Any agent, via the skills CLI (Claude Code, Codex, Cursor and more; it detects what you have):

npx skills add Leonxlnx/unlazy

Add -g for a user-level install or --all for every detected agent, non-interactively.

Claude Code, manually:

git clone https://github.com/Leonxlnx/unlazy ~/.claude/skills/unlazy

OpenAI Codex CLI, manually (invoke with $unlazy or let it trigger on the description):

git clone https://github.com/Leonxlnx/unlazy ~/.codex/skills/unlazy

Everything else: SKILL.md is a plain markdown file. Paste it as a system prompt, a Cursor rule, or a preamble. Gates and scripts need only Node 16+.

Hard mode (Claude Code, optional)

The skill works everywhere as discipline. In Claude Code it can also work as a wall: a Stop hook that structurally blocks ending the turn while gates are unmet.

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

It is a millisecond file scan, zero tokens per check. If the agent makes no gate progress across six consecutive blocked stops, the hook releases it with a warning instead of trapping it, and an ABANDON: <gate> <reason> line is always honored as an honest exit. Add .unlazy-hook-state.json to your .gitignore.

Or let your agent install it

Paste this to Claude Code, Codex, Cursor or any agent with shell access:

Install the "unlazy" skill from https://github.com/Leonxlnx/unlazy so it is
available to you in future sessions.

Try `npx skills add Leonxlnx/unlazy -y` first. If that is unavailable, clone
the repo into your own skills directory instead: ~/.claude/skills/unlazy for
Claude Code, ~/.codex/skills/unlazy for Codex CLI, or the equivalent path for
whatever agent you are.

Then confirm it worked: show me the installed path and the first line of the
skill's description. Do not tell me it is installed unless you have actually
verified the file is on disk.

What changed in v2, and why

The original single-file skill is preserved unchanged on the v1 branch if you want the instructions-only version with zero moving parts.

v1 was instructions. To find out what instructions actually buy, the method was put through 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. Every output was code-reviewed by independent agents, adversarially re-verified, and live-tested in a browser.

What the test found, in five lines:

Finding	Consequence for v2
Baseline already ships zero placeholders, zero console errors	The banned-list was fighting a solved problem; v2 aims at what actually failed
The skill raised effort 1.6-3.9x and fixed 4-10 self-found defects pre-delivery	The passes and gates discipline demonstrably work; they stay
tree 6 cost about 1.0-1.5x tree 3, never the promised 8x	The 2^(N-1) arithmetic was fiction; depth is now decomposition, not multiplication
The only hard live failure was a baseline build, and its report claimed the case was handled	Claims need runnable checks, not confidence; hence CHECK/EXPECT gates
Every skill run's final report contained 1-3 wrong numbers; baselines had zero	Hence the report audit rule: re-measure every number at report time

The deeper lesson: prose cannot enforce prose. A model that under-executes instructions also under-executes the instruction not to under-execute. So v2 moves enforcement down a hierarchy, each layer catching what the one above misses:

1. Discipline (SKILL.md): weakest layer, works in any agent.
2. Gates files (GATES.md, gates/*.md): intentions written at minute 2 stay sharp at minute 90.
3. Runnable checks (scripts/gate-check.mjs): a CHECK command decides, not a feeling of completion.
4. Parent re-verification (orchestrated mode): the dispatcher re-runs each leaf's checks; self-certification is worthless.
5. The Stop hook (scripts/stop-hook.mjs): ending the turn with unmet gates is blocked, mechanically.

How it works

Before real work starts, the agent writes its acceptance gates to a file:

# 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

gate-check.mjs runs the CHECK commands, flips boxes only when EXPECT matches, and records the deciding output lines as evidence. A checked box whose evidence still reads pending counts as unmet; a checkbox is a claim, evidence is the proof. Done means the ledger is full, and the final report pastes it, N of N, with every number re-measured at report time.

For big builds (tree 4+), the tree becomes a real plan: PLAN.md holds the contract (interfaces, file ownership, naming, fixed before fan-out), every leaf and branch gets its own gates file, and each leaf runs as a fresh subagent. Fresh context per leaf is t

...