kerby

This is not prose about the product. This is the product.

What it looks like when kerby says no

$ git push --force
BLOCKED: git push --force / -f
Reason: destructive git command — data loss is hard or impossible to undo.
If you really need this, run it yourself in a terminal.
See kerby guardrails (hooks/protect-git.sh).

$ vim .env
BLOCKED: '.env' already exists — replacing it would overwrite its current contents.
Env files are the one class git cannot restore — a real .env is gitignored, so an
overwrite has no undo. Hand the required variables to the user to add themselves:
  <VAR>=<value>
Placeholders belong in .env.example / .env.template / .env.sample — a regular file,
named absolutely, which is neither a symlink nor a hard link to another file.
See kerby guardrails (references/guardrails.md § Environment Files).

$ git commit
WARNING: gitleaks detected possible secrets in staged changes.
Output suppressed so the secret isn't echoed here — inspect locally with
'gitleaks stdin --redact', or allowlist a false positive in the scanner's config.

BLOCKED: git push --force / -f
Reason: destructive git command — data loss is hard or impossible to undo.
If you really need this, run it yourself in a terminal.
See kerby guardrails (hooks/protect-git.sh).

BLOCKED: '.env' already exists — replacing it would overwrite its current contents.
Env files are the one class git cannot restore — a real .env is gitignored, so an
overwrite has no undo. Hand the required variables to the user to add themselves:
  <VAR>=<value>
Placeholders belong in .env.example / .env.template / .env.sample — a regular file,
named absolutely, which is neither a symlink nor a hard link to another file.
See kerby guardrails (references/guardrails.md § Environment Files).

WARNING: gitleaks detected possible secrets in staged changes.
Output suppressed so the secret isn't echoed here — inspect locally with
'gitleaks stdin --redact', or allowlist a false positive in the scanner's config.

One motion. Any work.

1. GATE — an action arrives and stops at the threshold.
2. WEIGH — kerby checks it against the evidence: tests, diffs, approvals.
3. VERDICT — it passes, or it doesn't. There is no third option.

The engine is domain-blind. It loads a rulebook, watches the work, and renders verdicts. It doesn't know what coding is.

A rulebook is a folder: the rules for one kind of work, plus the checks that enforce them. Load the one that fits. Write your own when it doesn't. Rulebooks from outside your machine pass a one-time trust review before they can run.

• sweSoftware engineering: no claim without a fresh test behind it, no commit on a protected branch, no secret in the diff.Read the guide →
• skill-authoringFor repos that write agent skills: nothing ships as verified without a fresh evaluation of the exact text being shipped.Guide coming

The engine is finished machinery. The next rulebook is a folder you write. Write a rulebook →

Install

Or via the cross-platform CLI:

Then: /kerby loads the rules into the session. /kerby status checks they're still active.

Full documentation →