Engwire vs a GitHub Action
Where the review runs changes what it can reach.
A workflow can check out a pull request and run an agent on it, and plenty of teams should do exactly that. But CI and a laptop are not the same trade: they differ in where the instructions come from, whose credential pays, and whose configuration the agent starts with. Those differences are the whole of the comparison.
Where GitHub's own behaviour is described below, it is from GitHub's documentation; the rest is how CI ordinarily works, and Engwire's side was established by running it. The section after them says when the workflow is the better answer, because for a good number of teams it is.
01 — Where the workflow comes from
In a GitHub Action
On pull_request for an open pull request, GitHub resolves GITHUB_REF to refs/pull/PULL_REQUEST_NUMBER/merge — the pull request merged into its base. The workflow that runs is the one on that ref, so a branch may carry a change to it, which is why review on .github/ is worth owning. From a fork this is defanged by default — the token is read-only and, GITHUB_TOKEN aside, secrets are not passed — though an administrator of a private repository can turn on Send write tokens to workflows from pull requests where the organization's own policy allows it. From a branch in the repository itself, none of it applies.
On your machine
Claude runs with --setting-sources user, so a CLAUDE.md, .claude/settings.json or project skill in the pull request is inert — established by running it against named Claude Code versions rather than read about. A .mcp.json was observed inert too, on one version, by a method the published recipe does not reproduce.
02 — Whose credential it spends
In a GitHub Action
A model credential held as a plain repository secret is reachable by a workflow run on a branch of that repository. Scoping it to an environment whose protection rules keep an untrusted job out, or minting it per run through OIDC under a trust policy that restricts the claims, is the answer. Neither is one setting; both are a thing to set up and keep right.
On your machine
A review spends whatever your Claude Code is already authenticated with, on your machine. Engwire holds no credential of its own and adds nothing to the repository.
03 — Whose configuration it starts from
In a GitHub Action
A GitHub-hosted job does not carry a previous job's installed state, so the skill you have tuned is not on it. You can commit it, provision it from infrastructure you maintain, or keep a self-hosted runner that holds it between jobs — each a second copy of that configuration to keep current.
On your machine
The skill is the one already installed for you, improved without a release and without a commit. Engwire bundles none; Engwire publishes one to start from, and it is yours to edit once copied.
04 — Who the review comes from
In a GitHub Action
A workflow posts under the identity of the token it was given, which is not your account unless you make it one.
On your machine
The skill posts through your gh. The review arrives as you, because it is your account doing it.
The honest part
Use the workflow when any of this is true.
Engwire reviews the pull requests that ask for you, on the machine in front of you. That is a narrower job than CI does, and the cases below are ones it is not built for and will not grow into by configuration.
- use CIYou want every pull request in a repository reviewed for the whole team, whoever is online.
- use CIThe review has to run when nobody's machine is on — Engwire polls, and a closed laptop is not polling.
- use CIYou are reviewing pull requests from forks, which Engwire skips outright and offers no flag to allow.
- use CIMore than one review needs to run at once. Engwire runs exactly one, and there is no setting for a second.
- use CINobody wants to supervise a process on Linux. Engwire's background service is launchd; `docs/linux.md` ships a systemd unit that does the same job, but running it is yours.
If it is the other one you want
Reviews that come from you, on the machine that already has your tools.
curl -fsSL https://engwire.com/install.sh | shBoth, if you want
They are not exclusive, and the overlap is small: a workflow covering the repository, and Engwire answering the requests addressed to you with the skill you have tuned. What you should not do is put the same review in both places and read it twice.
The hosted product, for telling everyone else what shipped. Pre-launch.