Three headings, one comment, a fixed verdict word against each checklist item, and a hard list of things it may not do: approve, merge, label, assign. The shape is decided before the run begins, and the work is fetching the pull request, its files, its commits and its existing reviews, then filling that shape in. Codex is at home in bounded API work of exactly this kind.
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.
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.
Runs on Codex
Preselected for this page — connect your Codex account during setup, or switch to NoClick's built-in models with one click.
Watch it handle a test run
A staged conversation against a simulated world — then it’s live.
The same three parts arrive in the same order on every pull request, so a reviewer learns where to look once. Concrete output shapes are what this harness is most dependable on.
Pulling a pull request, its commits, its files and its reviews, then posting a single issue comment, is plain integration work. Nothing in the loop asks the harness to be inventive.
GitHub returns changed files in pages and the agent judges what it was handed, so on a very large diff plenty of items resolve to cannot tell with a reason attached instead of to a verdict. That is intended behaviour rather than a shortfall. Monorepo teams usually narrow the bar down to the paths they genuinely gate on.
Free to start. Guided setup, a test run against staged conversations, and it's live.