Primate
Primate checks pull requests the way a person would. It opens the pages a change touches, looks at them on desktop, tablet and mobile, and posts what it finds back on GitHub. I co-founded it and designed the product.
Too many pull requests, not enough checking.
AI tools made it easy to open a lot of pull requests, and nobody on a small team has time to click through every one at three screen sizes. That’s the job we built Primate to do.
It reads the diff, works out which pages are affected, and opens them in a real browser. Screenshots and anything that looks broken get posted as a comment on the pull request, and the full results live in Primate’s dashboard.
A lot of GitHub data, and not much room.
Most of my time went into two screens: the list of reviews, and the page for a single review. Both have to show a lot. Every run has a repository, a branch, a pull request number, a commit, a status, start and end times, a screenshot for each page and screen size, and the raw logs. Push to the same pull request five times and you have five of everything.
Showing all of that at once would have looked thorough and been useless, so I had to consider the following:
When someone opens this page, what do they actually want to know?
Almost always it’s “did my change pass?”, and if it didn’t, what broke. So that answer goes first on every screen, and the rest is a click or a scroll away.
One row per pull request.
A plain table, one line per pull request. Long titles are truncated, and status gets its own column so you can scan straight down it. On a phone, the rows become cards.
The answer at the top, the evidence underneath.
The summary comes first, with the status and, if the run failed, the reason right beside it. Then the screenshots, each with a one-line finding. The raw output is folded away until you need it.
Earlier runs collapse into a timeline. Opening one shows the same summary layout, so there’s nothing new to learn.
Prototypes instead of mockups.
I designed these screens as working prototypes in Claude Design rather than static frames. With realistic data in them, it was much easier to judge things like how titles truncate and how tight the rows could get. Once we agreed on a direction we built it with Claude Code, and Primate reviewed those pull requests too.
We also wanted it to be fun. Dev tools tend to look the same, so we leaned into the monkey theme, with bananas that light up as you pick repositories and an orangutan keeping you company through onboarding. QA is a chore, and we wanted using Primate to feel like a small pleasure.