GitHub Integration

Review every new pull request automatically, and @mention your runner on issues, pull requests and discussions.

Evident connects to GitHub in two independent ways. It can review new pull requests on its own and report the outcome as a check, and it can answer when someone @mentions it on an issue, pull request or discussion. They share one GitHub App installation, but you turn them on separately — and either works without the other.

Connect GitHub

An owner or admin installs the Evident GitHub App for the organisation and approves access. You are brought back to Evident and can see which repositories the runner can reach. More than one account can be connected, and the connection belongs to your team — a teammate who connects an account makes it visible to everyone. Each organisation has its own installation and its own settings.

If Evident later adds a permission to the App, the connection is shown as needing approval, with a pointer to where you can approve it on GitHub.

Pull request reviews

Once a runner is plugged in to review, Evident checks new pull requests without anyone mentioning it. It reads the diff, and the outcome appears as a check on the pull request.

Installing the App is not enough. Pull requests are not checked until you plug a runner in to review them. Until you do, Evident says nothing on your pull requests and spends nothing looking at what they changed. Plug a runner in once, and there is nothing else to turn on.

What you get back

  • A check, not a comment. Evident never adds a comment to the pull request's conversation. Any review remarks appear on the lines of code they are about.
  • The check shows up straight away, marked unfinished, and its details link to Evident's work on that pull request so you can watch it. When it finishes, the details link to the review it actually ran.
  • Nothing to say is still an answer. A pull request Evident is happy with gets a passing check and no remarks.
  • The author needs no Evident account, and is never asked to connect one.

What is not reviewed

Evident deliberately does not spend a review on everything, so it stays useful rather than noisy:

  • Draft pull requests. Pushing to a draft does not spend a check. Marking it ready for review does.
  • Documentation-only changes. A pull request whose changes so far only touch documentation does not spend a check. One that already changes code is still checked after a documentation-only push.
  • Rapid pushes are coalesced. Push several times in quick succession and Evident runs one check covering all of them.

The check is given the diff, not the story around it: it does not read the pull request's description. Successive pushes continue the same review conversation, so Evident remembers what it already flagged.

Choosing which runner reviews what

Each runner is plugged in either for every repository or for one specific repository, so two runners in the same organisation can review different repositories. A runner plugged in for a specific repository takes precedence over one reviewing every repository, and it does not check any other repository.

Reviews can run on a different OpenCode agent — and a different model — than the one answering @mentions, so you can review with a cheaper model without changing how mentions behave.

There is one organisation-wide switch, and it can only stop reviewing, never start it. Turning it off leaves your runners plugged in: turn it back on and the same runners resume, with nothing to reconnect.

When a review doesn't finish

A review that dies leaves the check unfinished — it never shows a passing check for that push. A review that finishes without reaching a clear conclusion shows neither a passing nor a failing check. In both cases Evident stays off the pull request's conversation.

Mentioning Evident

@mention @evident and your runner picks the message up. The reply is posted back where you asked, with a small "View in Evident" link to open the full conversation in the chat.

The mention must lead your message. "@evident can you look into this?" works. "I think @evident could help here" does not — Evident does not respond, and no conversation is created.

Where it works

  • Issue comments, and the body of a newly opened issue.
  • Pull request conversation comments.
  • Inline review comments on a line of code. Evident replies on that same review thread — it never starts a new one.
  • Discussions, on a top-level comment or a reply under one. Each top-level comment is its own conversation.

One exception worth knowing: a mention in the body of a newly opened pull request does not start a conversation. Evident still reviews the pull request as usual — comment on it instead if you want to ask something.

A whole pull request is a single conversation, shared by its conversation tab and every inline review thread, so Evident keeps the context as you move between them. Follow-up mentions on an issue continue the same conversation.

Who can trigger it

The person mentioning Evident needs either a linked GitHub account or to be allowlisted by an admin. Anyone else gets a reply telling them how to connect their GitHub account, and nothing else happens — no conversation is started and the runner never receives the message.

  • Link your own account from your Evident settings. From then on your mentions trigger the runner. Anyone on the team can do this for themselves — you do not need to be an admin.
  • Admins can allow an account by username — useful for someone who will never have an Evident account. Their conversations are attributed to that GitHub account, without impersonating an Evident user. A username that doesn't exist on GitHub is rejected rather than silently added.

Progress, questions and permissions

Evident reacts to your comment to show it is working, and swaps that reaction for the outcome when it finishes — including a failure reaction, with a comment naming the error, if the run fails. A short "Working on it" notice with a link is posted when it starts, once per thread, not on every mention.

When the runner has a question, or asks permission to do something, a notice is posted linking to the conversation and mentioning whoever triggered it. You answer in the runner's chat, not on GitHub — there are no answer choices, and no approve or deny controls, on GitHub. While it waits, the turn is not reported as done, and asking for the same input twice posts only one notice.

Settings

  • A default runner per connected account, with a per-repository override.
  • A default OpenCode agent and model for GitHub, also overridable per repository.
  • Extra trigger tags (admin). Add my-org-bot and @my-org-bot triggers Evident exactly like the built-in mention, which keeps working alongside it.
  • Allowed GitHub accounts (admin), listed separately from self-connected ones.

Disabling the integration makes Evident go quiet without losing your settings; enable it again and mentions work as before. Disconnecting the installation also unlinks the GitHub accounts that were linked through it.

When your runner is offline

Nothing is lost. Evident reacts to acknowledge the mention, holds the message, and delivers it when your runner reconnects — then replaces the acknowledgement with the outcome reaction.

Next steps