Leonxlnx/unlazy

What it claims

unlazy makes "done" mean "a declared command oracle passed." Each gate in GATES.md passes only when its CHECK: process exits 0 and its EXPECT: string matches combined stdout/stderr. The source targets version 2.1.0, which is not a tagged GitHub release. The authors advise pinning an exact commit if you need an immutable install. The checker and hook need Node 16+ and have no third-party runtime dependencies.

How it works

The checker's mode decides whether anything executes:

flowchart TD
  A[gate-check.mjs GATES.md] --> B{mode}
  B -->|--status| C[validate evidence binding, never executes]
  B -->|normal| D{exact approval record?}
  D -->|no| E[print command, EXPECT, CWD, shell, PATH; do not run]
  D -->|yes| F[execute CHECK]
  B -->|--approve / --reverify| F
  F --> G{exit 0 AND EXPECT matches?}
  G -->|yes| H[write digest-bound evidence]
  G -->|no| I[gate unmet]

• Normal mode is not a permanent dry run. Once a gate is approved, normal mode runs it.
• Output limit. Captured output over 1 MiB fails. It is never truncated into a success.
• Evidence binding. Evidence begins with a SHA-256 digest of CHECK:/EXPECT:/CWD:. Gates with prose, legacy or mismatched evidence count as stale and unmet. Manual gates with human evidence still work.
• Parser rejections. It rejects zero-gate ledgers, duplicate ids, and abandonments that lack a reason.
• Abandonment. A valid abandonment exits 1 with HANDOFF REQUIRED. It is never a success.
• Shell selection. The order is --shell, then UNLAZY_SHELL, then the platform default (/bin/sh, or ComSpec on Windows). Checks inherit PATH, so Git Bash and PowerShell launches can behave differently.
• Parallel orchestration. This lives under .unlazy/<scope>/ (PLAN.md, GATES.md, gates/leaf-*.md, gates/node-*.md).
• Leaves move through WAITING, READY, IN-FLIGHT, VERIFIED and ABANDONED.
• Before running in parallel, leaves must claim disjoint OWNS: paths.
• Gate checks run sequentially unless you pass --jobs N, where N is 1–64.
• Stop hook. It blocks while gates are unmet or launch waves are incomplete, but it never executes checks. After six consecutive blocks without semantic progress it gives up and lets the session stop. Metadata-only edits do not reset that count.

How to use it

npx skills add Leonxlnx/unlazy

Add -g for a user-level install or --all for every detected agent. For a manual install, clone into ~/.claude/skills/unlazy or ~/.codex/skills/unlazy. Invoke it as /unlazy or as $unlazy in Codex:

/unlazy tree 5 refactor the payment module and verify every migration path

For a solo task, copy templates/gates-leaf.md to GATES.md and run:

node <path-to-skill>/scripts/gate-check.mjs --status GATES.md
node <path-to-skill>/scripts/gate-check.mjs --approve GATES.md
node <path-to-skill>/scripts/gate-check.mjs --reverify GATES.md
node <path-to-skill>/scripts/gate-check.mjs --scope api --leaf leaf-1.2.1 --claim
node <path-to-skill>/scripts/install-hooks.mjs   # also --scope api, --uninstall

scripts/gate-lint.mjs is an advisory, non-executing linter for weak ledgers; add --strict to make warnings fail.

By default the hook installer writes .claude/settings.local.json and backs up the old file as <settings-file>.unlazy.bak. Add that file, .unlazy/ and .unlazy-hook-state.json to your ignore rules. --shared writes absolute paths into project settings, which usually isn't portable and can leak directory names. Run the test suite with npm test.

Limits

• Approval is consent, not a sandbox. Checks run with ambient filesystem, credential and network access.
• Approvals are stored in ~/.unlazy/approved, or wherever UNLAZY_APPROVAL_DIR points as long as it is outside the repo.
• Each approval binds the exact command, shell, CWD, limits, platform and full PATH.
• Approvals do not hash called scripts, fixtures or dependencies. If those change, re-inspect them and run --reverify.
• Evidence can be forged. The digest catches structural drift, not tampering. Anyone who can edit the ledger can forge evidence.
• Leases coordinate but don't isolate. They are conservative and may reject safe pairs. Use separate worktrees and caches when writes can collide.
• A gate only checks what you declare. The checker cannot tell whether a shell command actually matches the gate's English title. Gate quality is the user's responsibility.
• No benchmark evidence for the tool itself. Earlier README versions cited a six-run internal comparison, but its raw artifacts aren't in the repository. Treat it as historical, not a guarantee; a rerun protocol is in research/validation-protocol.md.
• The cited research motivates the design only. For example, SlopCodeBench's best agent passed 14.8% of checkpoints and none solved a problem end to end. The README says such work does not prove unlazy helps.