GitHub PR Review Agent

Somebody opens a pull request from a fork on Sunday and hears nothing until Wednesday, by which point they have moved on and whoever finally opens it has to rebuild the context from scratch. This agent takes the pull request apart the minute it appears, the changed files, the commits, any review already posted, then leaves one comment: what the change does, where it stands against your bar, and the two or three things a reviewer would genuinely ask. It cannot approve or merge, so the reading happens in the first minute and every decision stays with your people.

What people use it for

• Contributors hear back the same hour - A drive by fix from a fork gets a real response while the person who wrote it is still at their desk. Four days of silence is how open source loses the contributor who was going to fix the next three things too.
• One standard across every repository - Fork the template per repository and each gets the identical first pass, so the quiet side project is read as carefully as the flagship that everybody watches.
• Fork edits to CI get noticed - A first time contributor quietly touching a release workflow is the oldest supply chain trick there is. That case goes to your Slack channel naming the author and the file, and deliberately not into the public thread.
• It cannot tick your review gate - What it posts is an issue comment, which GitHub does not count as a review, so branch protection and required approvals are untouched. No change ships because software was satisfied with it.

Before you fork

Is it safe to run on pull requests from forks?

That is the case it was written for. It reads the pull request and posts one comment, and it is instructed to keep internal ticket references, customer names and roadmap detail out of anything on a public repository. Fork pull requests touching workflow or build files are reported to your Slack channel with the file named, rather than in a public thread where the observation would be most useful to whoever opened it.

Could it ever approve, or count toward our required reviews?

No, and that does not rest on instructions alone. It writes an issue comment, which GitHub treats as a comment rather than a review, so required approval counts and branch protection stay exactly as you set them. Give the credential repository read plus permission to write issue comments and there is no further reach to worry about.

What has to be connected, and how many runs is a busy week?

A GitHub credential able to read the repository and write issue comments, plus one Slack channel for the blocking cases. It fires once when a pull request opens and stays quiet through every later push, so forty pull requests in a week is forty runs and the size of your codebase changes nothing. Your checklist is the only setup, and there is no GitHub App to install.