writing-checkslisted

# Guards and gates Governs: shared/scripts/guards/, shared/scripts/gates/ Two mechanisms, one discipline. A **guard** reads one proposed action before it runs and may block it. A **gate** reads the worktree at CI time and may fail the build. Everything below applies to both, because the failure modes are the same. | | Guard | Gate | |---|---|---| | Sees | one tool call, as JSON on stdin | the whole tree | | Cost | every matching call | once per run | | Use when | the action is irreversible | the state is detectable | | Failure | exit 2, stderr goes to the model | non-zero, output goes to a human | ## A guard is a speed bump, not a boundary Say this out loud before writing one, because the rest of this skill reads like a promise it cannot keep. A guard matches the *text* of a proposed command: ``` git push origin main | tail -5 BLOCKED B=push; git $B origin main | tail -5 allowed ``` It also fails open on purpose — a broken guard must not become an unbypassable wall — so its coverage is best-effort in two independent directions. That is the right trade for what a guard is actually for: catching the thing you were about to do out of habit, and explaining why, at the moment you were doing it. It is the wrong trade for anything adversarial, and for anything where a single miss is unacceptable. Those get **three** layers, in this order: | | Mechanism | Why it is stronger | |---|---|---| | 1 | `permissions.deny` in `.claude/settings.json` | Evaluated by the har