The full upstream README, mirrored here for reference. Install config, tool schemas, adoption signals, and an original overview live on the Gate listing page.
One ship/no-ship verdict from your whole nugehs toolchain.

gate runs aiglare,
bouncer,
tieline and
repoctx against a repo and
merges their four dialects into one normalized verdict. Each tool already
answers a different "can this ship?" question — gate is the place they finally
agree on the answer.
Each tool's native result is normalized onto one status vocabulary:
| Status | Meaning |
|---|---|
pass | the check ran and is clean |
warn | ran, found something worth a look — not blocking |
fail | ran, found a blocking problem |
unknown | ran, but couldn't determine — explicitly not a pass |
skipped | not applicable / not configured for this repo |
error | the tool couldn't be run, or returned garbage |
The top-level verdict is the worst across the domains that actually ran
(skipped never counts). unknown and error roll up to warn so nothing
slips through as a silent pass.
| Tool | Native signal | → gate |
|---|---|---|
| aiglare | a red surface on a side-effectful sink | fail; any red/amber → warn |
| bouncer | a fail finding (missing required control) | fail; any unknown control → unknown |
| tieline | drift > 0 (FE call with no BE route) | fail; unverifiable > 0 → warn |
| repoctx | FAIL/BLOCK merge verdict | fail; WARN → warn |
gate runs aiglare without
--ciand derives the blocking verdict itself, so a tool thatprocess.exit()s before flushing its pipe can't truncate the report it feeds us.
A run that checked nothing is not a pass. If every domain is skipped or
deselected (e.g. --skip them all, or a typo'd --only), gate reports NO
CHECKS RAN (ok:false) and fails under --ci — a misconfiguration can't
silently turn the gate green.
On repoctx + local mode. repoctx's merge-readiness gate can only verify
review state (approvals, CODEOWNERS, required checks) against a host like
GitHub. Run locally it reports those as a WARN, so on a clean local repo gate
will often show merge readiness: warn. That's repoctx being honest about what
it can't see locally — not a problem with your change.
By default only a fail verdict blocks under --ci — safe to adopt without
drowning a team in warnings. Add --strict when you want warnings to gate too.
gate doesn't bundle the four tools; it finds each one at runtime. Per tool, first hit wins:
GATE_<TOOL>_BIN environment variable (explicit override)@nugehs/<tool> package (from node_modules)../<tool> (local development)A tool that can't be resolved is reported as skipped, never a hard failure —
so gate is safe to run in a repo that only uses some of the toolchain.
For a machine-readable record, --json emits the full verdict (schema version,
per-domain results, counts, and the blocking reasons) for dashboards or audit
evidence.
gate is also an MCP server, so an agent can ask "can this ship?" in one call — the unified verdict, not four separate tools.
Tools:
| Tool | Returns |
|---|---|
gate_check | the unified verdict for a repo (path, optional only/skip/ci/strict) |
list_checks | the four checks gate runs, each with its domain and what it answers |
Registry manifest: server.json (io.github.nugehs/gate).
The same normalized verdict drives a VS Code / Cursor extension
(clients/vscode) — the gates, shifted left from CI into the
editor:
@gate chat participant, a gate_check tool agent
mode can call before it says "done", and an MCP server provider — so the
assistant writing the code is checked by the same gate as CI;gate is the shared spine. The same JSON already drives the CLI, the --ci gate,
the MCP server, and the editor extension above. Next client on the same JSON:
*-web sites.MIT © Oluwasegun Olumbe