bpcakes/jig-sh

> **Keep coding agents on contract.**
Coding agents are good at writing code and bad at operating repositories. They
guess the test command, skip the lint step, run checks from the wrong directory,
and leave no record of what they verified. Every repository answers this with a
different mix of Makefiles, scripts, and prose, and every agent has to rediscover
it.
Jig replaces that with one repo-local contract. It turns your repository's
commands, ownership boundaries, and definition of done into a typed catalog that
humans, CI, and agents all run through the same entrypoint, scripts/jig, with
every run recorded. Around that contract it ships the local runtime a
repository needs day to day: a dev proxy with stable hostnames, an encrypted
vault for secrets, scheduled agent loops, and a terminal dashboard.
See it in 30 seconds
Add Jig to a Rust, Go, or TypeScript repository you already have. Adoption
previews by default and writes nothing until you re-run it with --write:
The preview shows what Jig found and what it would change (trimmed):
From then on, every operator uses the same commands and gets the same answers:
Add --json to any command for structured output. Add --affected BASE to a
check to run only the targets whose declared inputs changed since BASE. Every
check appends a record to .agent/state/runs.jsonl, so "the tests passed"
becomes something you can inspect with scripts/jig state summary instead of
something you take on trust.
Why Jig
- **Agents stop guessing.** The command catalog, the root AGENTS.md, and the
per-crate agent-map.md are generated together, so an agent learns how to
operate the repository from the repository itself.
- **One entrypoint for humans, CI, and agents.** The same scripts/jig check test
runs on a laptop, in the generated GitHub Actions workflows, and inside an
agent session. Nobody maintains three copies of the test command.
- **Checks leave evidence.** Each run records its target, exit code, and output
tail in repo-local history. Failed runs can be reviewed after the fact, and
scheduled agent loops record what each occurrence observed and did.
- **Affected selection from checked-in policy.** Actions declare their inputs,
so --affected picks targets from what actually changed instead of running
everything or trusting an agent to choose.
- **Updates never clobber your code.** jig update advances the managed harness
files and refuses to overwrite files you customised unless you pass --force.
Scaffolded application code is project-owned from the first render.
- **Local runtime, no service.** The dev proxy, the vault, agent loops, and the
dashboard all run on your machine against local state. Nothing phones home.
A Makefile and a hand-written AGENTS.md get you part of the way. What they do
not give you is machine-readable targets with declared inputs and effects,
affected selection that CI and agents can trust, a record per check, and harness
updates that know which files you changed.
Jig is for teams running coding agents such as Claude Code or Codex against
real repositories, and for anyone who wants scripts/jig check test to mean the
same thing on every machine. It is not a build system or a CI provider: it does
not replace Cargo, Go tooling, package managers, Nx, Turborepo, Dagger, Taskfile,
or GitHub Actions. It gives those tools one stack-neutral front door and
connects their results to repository guidance and run history. Linux and macOS
are supported hosts; see Platform Support.
Install
Install the latest prebuilt CLI on Linux or macOS. The installer needs curl and
Python 3, not Rust:
It selects your architecture, verifies the SHA-256 checksum and the executable's
version, and installs jig to ~/.local/bin, printing the PATH command if
needed. Run it again to upgrade; an existing executable is replaced only after
verification succeeds. To choose an exact release or installation directory: