GitHub PR Review Agent
Reads every pull request the minute it opens and leaves one comment with a plain read of the change, a verdict on each checklist item with the file that decides it, and the questions worth asking, while holding no power to approve or merge.
Watch it work before it's live
Run a staged conversation — no account needed. The agent handles it for real while a simulated world answers its tool calls; nothing touches real accounts, and nothing is actually sent.
Stream tile responses instead of buffering the whole body
Openopened by @marijke-devos
Replaces the buffered writer in the tile handler with a streaming encoder, so a 40MB vector tile stops sitting in memory before the first byte goes out. Nine files, 214 lines added, 118 removed, all under internal/tiles. Adds a benchmark showing peak memory falling from 96MB to 11MB on the Jakarta extract, plus table tests for the partial write path. The description links issue 402 and states the wire format is unchanged.
Set up in minutes
Using this template drops you into a guided setup. It asks exactly this, nothing else:
Connect GitHub
One sign-in. The agent acts through your account, scoped to what this template uses.
Connect Slack
One sign-in. The agent acts through your account, scoped to what this template uses.
Review checklist
What a pull request has to satisfy in this repository, put the way you would explain it to somebody reviewing here for the first time: which items are hard blockers, which paths you treat as sensitive, and what you want asked when the diff alone cannot settle one.
Choose which agent runs it
NoClick's built-in models work out of the box — or bring Claude Code, Codex, and other coding agents on your own subscription.
Watch it handle a test run
A staged conversation against a simulated world — then it’s live.
About this 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.
Run it with your coding agent
More agents like this
Put GitHub PR Review Agent to work
Free to start. Guided setup, a test run against staged conversations, and it's live.