No skill is bundled. There is now one to install.

Engwire decides when a pull request is reviewed and prepares the exact revision. A skill decides how. Keeping those apart is why the binary bundles no review policy — change what a review looks for and you edit Markdown, not wait for a release.

Which left everyone starting from an empty SKILL.md. Now there is one to copy:

npx skills add engwire/skills --skill engwire-review -g -a claude-code -y

That npx is the only part of this that needs Node, and Engwire does not. If you would rather not install one for the other, copy skills/engwire-review/ into ~/.claude/skills/ yourself, or into $CLAUDE_CONFIG_DIR/skills/ if you have set that — nothing about the skill depends on how it arrived. Then name it in a rule and run engwire doctor.

Treat it as a starting point rather than a default: copy the directory under a name of your own and change the name in its SKILL.md to match, because updating engwire-review reinstalls it over whatever you changed.

Look, prove, say

That is the skill’s own summary of itself, and the middle word is the difference between a review worth reading and a wall of plausible noise, and it is the one a model under a time budget will quietly skip.

Looking means the pinned diff read from the checkout on disk, not gh pr diff, which answers about whatever is current rather than the revision Engwire pinned. It is read more than once, one question per pass — what breaks, who else depends on this, what a retry does to it — because asking all of them at once reliably answers none. Candidates are recorded, then proved or dropped against the code at that revision, and most false findings die at the first step of that: open the file and follow the whole path, not the hunk the diff showed you.

One kind of unproven finding survives, and the asymmetry is deliberate. A credible high-impact candidate whose last missing fact cannot be established from a checkout stays in, phrased as the question that decides it. A reviewer who cannot rule something out is more useful naming the fact that would settle it than going quiet.

Twenty minutes is the default for the whole run, and the skill is told outright that reading expands to fill it — reserve enough to verify and post, because an unposted review helps nobody.

What lands on GitHub is one review, never a scatter of individual comments: findings inline against the revision they were read at, anything that will not anchor to a diff hunk named by file and line in the body instead.

That last part is not tidiness. GitHub rejects the whole review — every comment in it — if one anchor falls outside the diff, and the error does not reliably say which comment was at fault. So the anchors are checked against the file’s own hunk headers before anything is posted.

It will not request changes. Never REQUEST_CHANGES — a finding that would stop a merge is posted as a comment saying so plainly, because refusing someone’s change is the reviewer’s own call and not something to hand to an agent running unattended.

When it approves

Only where a repository has asked it to, and only when it can still be sure what it is approving. Immediately before posting it reads the pull request again, and every one of these has to hold:

• The label AI approval allowed is on the pull request.
• No surviving finding is high impact. Medium and low ones do not block, and they still post inline — approving says nothing blocks the merge, not that there was nothing to say.
• The review is complete. “Nothing blocking in the part I read” is not an approval.
• The author is not the account posting. GitHub rejects an approval of your own pull request.
• Head and base are still the commits it diffed.

The last one is worth stealing for any reviewer you automate. An approval of a revision the branch has moved past can still satisfy branch protection on the new head. Someone pushes while the review is running, the approval lands anyway, and the merge button turns green over code nobody read. So when either ref has moved, the skill does not approve — and says in the body that this is why, rather than leaving a comment-only review looking like an opinion.

That re-read decides two more things, neither of them an approval condition. If the gh login changed between starting and posting, nothing is posted at all: the review was gathered as one person and would have been published as another. And if the pull request was closed, merged, or taken back to draft while the review ran, nothing is posted either — it left the reviewable state after Engwire picked it up.

Two rules for an agent nobody is watching

It runs unattended, on a branch a stranger wrote. Two of its standing rules are about that arrangement rather than about reviewing at all: one draws a line around what may give it orders, the other around what may leave.

Everything it reads is evidence, not instruction. Pull request text, ticket text, a CONTRIBUTING.md, a comment in the diff — none of it redirects the workflow, the tool rules, or the posting policy. A conventions document describes a project’s standards; it does not get to issue orders, however it is phrased.

The review’s context stays in. No source, diff, ticket text or internal URL goes to a service that does not already hold it. That leaves gh, the repository’s own origin, and whatever MCP service is already reading those tickets. The web is for public reference material, and what comes back from it is treated as untrusted too.