Engwire v0.1.0
The first release. It ships no reviewer, reviews nothing until you name a repository, and promotes no tag until every binary has run off the machine that built it.
Engwire reviews the pull requests on GitHub.com that ask for your review, on your own machine, under your own GitHub account and Claude subscription. There is no Engwire account and no Engwire server: it drives the git, gh and Claude Code you already have, your code goes nowhere it was not already going, and the review posts as you.
curl -fsSL https://engwire.com/install.sh | sh
One binary into ~/.local/bin. macOS 13+ and Linux with glibc 2.17+, Intel and ARM — the x64 builds require AVX2, so Haswell-era Intel or newer, Excavator or newer on AMD, and musl distributions such as Alpine are not supported yet. Those are Bun’s floors rather than ours, since the binary carries its own runtime. The installer runs what it downloaded before moving it into place, so a machine below those floors finds out without losing the installation it already had.
What v0.1.0 does not ship is a reviewer. Engwire invokes a Claude Code skill you own, as /<skill> <repo>#<number> at <sha>, and what a review reads, says and posts under your name stays that skill’s business. There is one to start from, and engwire doctor checks the one you configured against everything Engwire can establish without running it — a skill that fails that preflight leaves its reviews queued rather than spending them on a run that does nothing. It cannot promise Claude will invoke the skill. Nothing local can.
engwire setup then writes a config with every rule commented out, and engwire run refuses to start until you uncomment one. The refusal is not squeamishness about starting an agent on a contributor’s code, though that is reason enough. It is that a review request Engwire declines is dismissed for good: a runner with no rules would quietly mark every outstanding request no_automation and never look at it again. Better to refuse the whole process than to burn the backlog silently.
Once it does start, run polls until you stop it and --once takes a single pass. Pull requests from forks are dismissed rather than reviewed: a rule naming a repository says a change was proposed somewhere trusted, not that it came from someone trusted. Background supervision is macOS-only in this release — on Linux you supply the supervisor, and docs/linux.md has a systemd unit that does what the launchd job does, with a note on why each setting is there.
The tag is what publishes, and it does not trust its own build. Typecheck, unit tests and integration tests against the real binary run on a Linux and a macOS host before anything is uploaded, but four artifacts are cross-compiled from one machine, so two of them — an Intel Mac and an ARM Linux box — have executed nowhere at all at that point. So a tag ships first as a prerelease, and one runner per platform installs it the way you would: the published install.sh off the release rather than the copy in the repository, fetched by tag with an unauthenticated curl, no token and no checkout. That last step proves only that each artifact starts on its own architecture, which is a low bar and exactly the one worth holding. Skip it and the first machine to find out is somebody else’s.
If you want to try it: install, engwire setup, uncomment one rule, engwire doctor, then engwire run --once against a repository whose pull requests you already read. A single pass is the honest first move — you see exactly one review before deciding whether to leave anything running.