Gatewright
Evidence-gated work tracking for coding agents. File-first, provider-agnostic, zero dependencies.
Work that earns its way forward.
The problem
Every coding-agent session starts from zero: the agent doesn't know what is in flight, what is blocked, or what it was supposed to pick up next, so the human re-explains it, or the agent re-reads a wall of markdown and burns context before writing a line of code. When the session ends, the record of what happened lives in a chat transcript nobody will open again.
The 60-second quickstart
Install once, then use gw from anywhere:
npm install -g gatewright # puts `gw` on PATH
gw init --pipeline solo
gw add "Wire the scheduler tick loop" --phase P1 --type feature --priority P1
gw claim T-0001
gw move T-0001 building
gw edit T-0001 --scope "Scheduler tick fires once per tick_s and never overlaps a run in flight"
gw move T-0001 done --evidence abc1234 --evidence test/scheduler.test.js
gw brief
gw serveCapture is one command with no required flags: phase, type and priority start out null, because at the moment you write a title down you genuinely may not know them yet, and guessing is worse than leaving them unset. add → claim → move … building is the whole path to "I am working on this" — no mandatory edit stands in the way. Rigor still applies; it just applies where a claim of completion is made. In the solo pipeline, reaching done needs a scope (what "done" means) and evidence that looks like evidence — a commit SHA, a file path, or a link — because that is the step where the claim needs to hold up, not the step where the idea got written down.
No global install? Use npx gatewright <command for each command instead. The package ships both gw and gatewright as binary names so a gw collision on your PATH is never a blocker.
In a terminal, init walks you through three screens driven by the arrow keys, and each one explains its question and every option in plain English: how you want to work (Solo or Team), what to set up (instruction files for your AI tools and a commit check, ticked with Space; AGENTS.md is always written, and a tool already found in the project starts ticked), and a review listing every file that will be written. Nothing is written until you confirm the review; Esc or Ctrl-C at any screen leaves the directory untouched. Terminals that cannot run a full-screen picker (TERM=dumb, a legacy Windows console, or GWTUI=0) get the same workflow question as a numbered prompt instead. Solo installs backlog → building → done, with no PR stage or policy hold for agent-created work. Team installs backlog → building → built → inreview → reviewed → merged → verified, with PR review and triage. With --yes, a GitHub origin selects team; otherwise it selects solo.
Step 1 of gw init: choose how you want to work. Each option lists its stages and says what choosing it means.
Step 2: pick what to set up. A tool already found in the project starts ticked; Space toggles the rest.
In a Git repository, init installs the commit hook unless you pass --no-hook. It finishes by pointing at gw serve for the live board.
init creates .gatewright/ (items, events, stages, config, prompt), writes an instruction block to AGENTS.md, and baselines .digest. gw open writes board.html. The CLI and the live board's write API are the only write paths; the snapshot board is written on demand.
The refusal
A card in Built has evidence because it could not have got there without it. gw move evaluates the target stage's exit rule from stages.json and refuses the move if the rule is unmet.
$ gw move T-0001 built
target stage requirements are not met
built: needs a scope: run `gw edit T-0001 --scope "<what done looks like>"`
built: Needs at least one new piece of evidence, distinct from anything already recorded: run `gw move T-0001 built --evidence "<commit sha, test path, or URL>"`
built: Evidence supplied with the move must look like a commit, a file path, or a link: run `gw move T-0001 built --evidence "<commit sha, test path, or URL>"`
$ echo $?
1