Unlazy

The failure this skill kills 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. Prose instructions cannot catch these failures; the ones that survive instructions are exactly wrong self-reported numbers and stalls that feel like completion. So enforcement lives in files and runnable checks, not in goodwill. You do not promise you are done. You prove it against a ledger.

This skill governs gate discipline on a decomposition; it composes with work, incremental, and subagent-driven rather than replacing them.

Rule zero: gates before work

Before real work starts, write the acceptance gates to a file: .outline/GATES.md in the working directory, using templates/gates.md. One checkbox per outcome the task requires. Wherever an outcome is command-checkable, give it a CHECK: line (the runnable command) and an EXPECT: line (the output that decides it), so the check is a subprocess rather than an opinion.

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

The gate contract, in Hoare's register: CHECK is the test, EXPECT is the postcondition, EVIDENCE: is the recorded proof. A checked box is a claim; evidence is the proof. A checked box whose evidence still reads pending counts as worse than unchecked, because checked-without-evidence is the exact failure this system exists to catch.

If a gate becomes genuinely impossible, do not quietly drop it. Add ABANDON: <gate id> <reason> to the gates file and say so in your report. Visible surrender is honest; silent scope-narrowing is not. The tooling treats an ABANDON line as a resolved exit, not a failure.

Enforcement

Run the bundled checker to execute CHECK commands, flip boxes, and record evidence: