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.