Skip to content

v0.1.0

Choose a tag to compare

@janit janit released this 19 Sep 12:52
· 9 commits to main since this release

Feed the gator. Hand a chunk of work to a bigger model and it chews on it in
an isolated git worktree on its own branch β€” merged back only when it builds and
tests clean.

gator feed --title "port the tokenizer" --role heavy \
           --scope "src/lexer.ts,src/lexer_test.ts" --task @task.md
gator wait

One SKILL.md and two shell scripts. No plugin, no host API: any agent that reads
skills/<name>/SKILL.md and can run a shell command can use it β€” OpenCode, Pi,
Claude Code.

Why a script and not a plugin tool

Delegation fails at one step: getting the model to choose it. Measured against a
603-line build brief with Qwen3.8-27B as the chat model, a delegate tool reached
through a plugin's code mode was called in 0 of 5 runs; the same model reached
for this script in 5 of 7 (Fisher exact, two-sided p = 0.0278). In one of those
runs the model made 179 shell calls and 2 execute calls. shell is the tool
these models live in, so that is where feeding belongs.

The same benchmark at the API level: with a file-reading tool available, neither
granite-4.2-8b nor Qwen3.8-27B delegated β€” 0/9 each. Remove read and Qwen goes
9/9. Model size was never the constraint.

Merge only when green

Each chunk is built and tested inside its own worktree before anything is
merged, so a broken one costs a merge that never happened rather than a rollback
of your work. In the same study a delegated implementation scored 90/301 as
delivered and 299/301 after fixing two characters in an import path β€” 209
points lost because nothing ran the build. A chunk that does not build comes back
unverified, keeps its worktree, and hands you the build output.

The verify command is detected from the project (deno task build && deno task test, npm test, cargo test), or set in .gator/verify or GATOR_VERIFY.

What else is in it

  • Limits enforced in the script, not asked of a model: a minimum chunk size, scope
    required, dedup by task hash, a feeding budget, digestion time between feedings,
    and a cap on how many chunks it chews at once.
  • Chunks are chewed detached, so one outlives the tool call that fed it and
    survives the session being interrupted.
  • Roles live in ~/.config/gator/roles, so no model id is in the code and no shell
    profile has to be edited.
  • Statuses that refuse to flatter: empty when it spat the chunk out, unverified
    when it does not build, ready (held) when your tree is dirty.
  • deno task test stubs the worker, so every limit, every status and the
    verification gate run in about seven seconds without touching a model.

docs/evidence.md has the measurements behind each decision, including what they
do not prove: one fleet, two quantised local models, one workload.