Done only when the gates pass.
gatebound is a gate-enforced harness for AI coding. It turns the rules you'd write in a CLAUDE.md into hooks that actually run, every time: spec before code, approvals that go stale when the file changes, and a completion contract of real commands instead of an agent's word.
Prose is a suggestion. A hook is a rule.
An instruction in a prompt is only as reliable as the model's attention in that turn. gatebound moves the parts that matter into gates the host runs on every tool call and at every turn end.
Instructions the model can skip
"Write tests first." "Get approval before touching src/." "Don't say done until it works." Under pressure, any of these can quietly not happen.
# CLAUDE.md - write the spec before code - run the tests before saying done
Gates the host enforces
A write to src/ before the spec is approved is denied. A turn that claims done runs the contract first. A check that couldn't run says so.
PreToolUse · write gate gatekit: writing code is blocked until spec/05-gate.md is approved Stop · stop gate gatekit: the completion contract is not met, so this work is not done
Watch a gate fire
An agent asked to build a login page in Claude Code. The red lines are the plugin's actual messages; the file names, criterion id and hash come from an example project.
Hook messages follow your language: write in Korean and the same gates answer in Korean. gatekit approve and gatekit contract run are shorthand for the plugin's CLI (python3 …/bin/gatekit.py), which the commands run for you; the name becomes gatebound with the rename.
From one sentence to a verified change
Every stage writes plain Markdown and JSON under spec/, meant to be reviewed and committed. The build only opens once the gate is approved, and the agent that built something never signs off on it.
What the gates give you
Small, mechanical guarantees that add up to a build you can trust.
Hash-anchored approvals
Approving a spec records its SHA-256. Edit the file afterward and the approval is stale. Nobody has to remember to re-review.
Executable "done"
Completion is a list of commands that exit 0 and produce the expected artifacts, or they don't. No done on the honor system.
Assumption ledger
Every guess made on your behalf is written down, so nothing gets decided silently.
Four-state verdicts
A check that couldn't run is never rounded to a pass.
Producer ≠ evaluator
Verification runs in a separate, read-only agent, optionally the other CLI, so a model doesn't grade its own work.
Fails open, never hangs
A broken gate script degrades to "allow and log." Standard-library Python only, no pip install.
Quickstart
From install to a verified change in four steps. Hooks stand down in any project you haven't set up, so nothing changes until you run a command there.
Install, then restart the host
- 2
Write the spec
Open your own project and start with
/gatekit:discoverif you're still deciding what to build, or/gatekit:interviewif you already know. You getspec/01-prd.mdandspec/03-architecture.md, with every assumption made for you listed in a ledger. - 3
Approve the gate
Run
/gatekit:tasks, then/gatekit:gate. Read the completion criteria and approve them. The approval pins the file's hash: from here source files can be written, and editing the gate later expires the approval. - 4
Build, then verify
Run
/gatekit:build. Each task is judged by its gates, and a turn that claims done runs the contract first. Finish with/gatekit:verify, where a separate read-only agent checks the result.
In Codex the same commands are skills: $gatekit-discover, $gatekit-gate and so on. If something looks off, /gatekit:doctor checks the install and prints a fix for anything that isn't ok.
gatekit name. Projects written today keep working afterward: the current release already reads both names.python3, python or py -3. Nothing else to install.FAQ
How is this different from rules in CLAUDE.md or a prompt?
A rule in CLAUDE.md is advice the model may or may not follow in a given turn. gatebound turns the rules that matter into hooks the host runs on every tool call and at every turn end. A write before the spec is approved is denied, and a turn that claims done runs the completion contract first. The model doesn't have to remember anything for the rule to hold.
Does it slow the agent down?
Most gates are a quick check of a file path or a hash. The heavier part is the completion contract, which runs only during a build, at the end of a turn. It starts criteria for up to 120 seconds by default (stop.budget_s); the rest run at the next turn end. When no file changed since the last run, the previous result is reused instead of running again.
Will it change projects where I don't use it?
No. The plugin installs globally, but its hooks stand down in any project without a .gatekit/ directory: no gate acts and nothing is written. A project opts in the first time you run one of its commands there.
Can the agent just edit the gate or its approval?
Editing spec/05-gate.md after approval expires the approval, so the build stops until you approve again. The approval records and the derived contract under .gatekit/ are written only by gatebound's own hooks and CLI; a direct edit by the agent is denied. A worker session can never approve anything.
What happens if a gate itself breaks?
It fails open. A gate that hits an internal error allows the action and writes a one-line diagnostic to .gatekit/runs/hook-errors.log, so a bug in gatebound never hangs your session. /gatekit:doctor checks the install and prints a fix for anything that isn't ok.
Does it send my code anywhere?
gatebound makes no network requests of its own. It is standard-library Python with nothing to pip install, and it never holds an API key. The only connection it opens is a doctor check for a local dev server on 127.0.0.1. The commands in your contract, and the claude or codex CLI if you use one as a worker, run exactly as you configure them.
Does it work in Codex and on Windows?
Codex installs the same plugin from the same marketplace, and the write, shell, stop and prompt gates run there too. Codex asks you to trust the hooks once (run codex, then /hooks). Windows support is in preview: CI runs on Windows, and Claude Code runs the hooks through Git for Windows. WSL behaves like Linux.