What an install requires

Supported systems

An install is possible only on a system below, where a prebuilt gate binary is published. Every joined system is built and installed on every push, on the runner images native/runners.list names.

joined means the current release publishes a binary for that system, at the floor shown; held means it is supported but not published yet, and names the run that would publish it. On any other system init refuses. On Linux, init takes the glibc binary where it runs and the static one everywhere else. Windows Subsystem for Linux (WSL) takes the Linux binary.

Installing and running the shipped gates

The tools each shipped gate runs. required binds every install. An optional row binds you only under the condition it names:

The install itself and the optional docs gates need these as well. doctor does not probe them:

The hook wiring the kits ship for Claude Code names the gate binary as the hook’s command and passes --hook and the member in an args array, so the harness starts it with no shell. That takes Claude Code 2.1.139 or later. The floor is read from Claude Code’s changelog, whose entry for that version adds the hook args field, and is not run here: the wiring was run on 2.1.292, and no build below the floor was tried. What an older build does with a registration carrying args is undocumented, so do not merge the wiring on one.

A missing tool comes from your distribution’s package on Linux or WSL, from Homebrew on macOS, or from Chocolatey on native Windows. To check your machine, run the gate binary with --emit env-probe: it writes an untracked ENV.local.md with each tool’s version and verdict. Building Checkwright itself takes more: see the contributing guide.

What a commit costs

The pre-commit hook runs the gates your profile registers whose triggers match the staged files. It runs them one after another and stops at the first red. The figure runs every gate whose triggers match a file over every tracked file, in a repository the one-line install has just initialized with full, the profile that contains every other. A gate that reads the staged set from git itself sees nothing staged, so the figure is a reference reading, not a ceiling.

On linux x86_64 with 14 logical CPUs, the hook ran 49 pre-commit gates over every tracked file in 2141 ms, the median of three, measured at v0.31.0.

To measure your own repository, run the gate binary with --measure-commit. It stages nothing and times the same run over every tracked file. Two costs sit outside the figure. First, the hook’s own start: git starts it with no shell on any OS, and the gates workflow’s probe step prints what that costs on each OS and architecture. Second, a gate you register yourself adds its own time.

Writing your own shell gates

A gate you write is a copy of gate-sdk’s templates/check-skeleton.sh. It is a bash script that sources gate-sdk’s library, so it needs the bash floor above on every system, whatever your profile. doctor checks it once your gates.list registers the gate. On native Windows that bash is Git for Windows’ bash: a gate cannot be written in PowerShell today. check-shellcheck lints your gate if you register it, and then shellcheck’s row binds you.

Writing your own Rust gates

There is no supported path today: a compiled gate is a subcommand of the published gate binary, and an install carries no crate to add one to. A fork that adds the subcommand and ships its own build can, since descriptors resolve consumer-first and so its own .gate descriptor runs. That fork then owns its own release, digest and upgrades, outside this project’s. gate-sdk/SPEC.md owns this.