Explain a pull request in plain English
Paste a link to a public GitHub pull request. You get what it changes for your users, how risky it is, what to try before you approve it, and the questions worth asking the author. No signup, no access to your code, and nothing is posted to GitHub.
Public pull requests only. Nothing is posted to GitHub.
What it reads
- The pull request
- Title, description, author, status and size, from GitHub's public API.
- Every changed file
- Up to 300 files, each sorted into a part of the product: screens, wording, server, database, sign-in, payments, settings, analytics.
- The changes
- The line-by-line diff, riskiest areas first, up to about 30,000 characters. Lockfiles are counted but not read.
- Risk signals
- Database migrations, environment variables that may be new, new dependencies, deleted files, and code that changed without a test.
- What it writes
- A plain-English summary, what users will notice, steps to try in a preview, and questions to ask the author.
Why read a pull request you can't code
Approving a pull request as a product manager is not a code review. Engineers check how the code is written. Your part is whether the change does what was asked, whether it does anything that was not asked, and what could go wrong for customers once it ships.
All three can be answered without reading code if you know where to look. The files a pull request touches say which parts of the product it reaches: a change confined to wording and styles is a different conversation from one that touches sign-in, payments or the database. The description says what the author meant to do. The preview shows what they actually did.
This tool does the first two for you and tells you what to try in the third. It does not replace opening the preview and using the feature, because a change can read well and still behave badly. It means you open that preview knowing what to look for, and talk to the author knowing what to ask.
What it cannot tell you
- Whether the change works. It reads the diff; it does not run the code. Only the preview can show you that.
- Anything in a private repository. This page reads public data only.
- The whole of a very large pull request. It reads the riskiest files first and judges the rest by name.
- Whether the code is well written. A low risk level means nothing sensitive was touched, not that the change is correct.
- Things the author did not write down. The plain-English summary is written by an AI model from the diff and the description, and it can be wrong, most often when the description is empty.
When it cannot tell something from the diff, it says so. A pull request you are about to approve deserves an honest “this does not say” more than a confident guess.
Before you paste a link
Do I need to give you access to my code?
No. The explainer reads a public pull request through GitHub's public API: the same title, description and changes anyone can see on github.com. You do not sign in, and nothing is installed on your repository.
Can it explain a pull request in a private repository?
Not on this page. It only reads public data, and a private pull request looks the same to it as one that does not exist. For changes Refinar makes in a private repository you connect, you see each one in a live preview before its pull request is opened.
Does it comment on the pull request or change anything on GitHub?
No. Every request is a read. It never comments, reviews, approves, labels or notifies anyone, so the author will not know you looked.
How accurate is it? Can it be wrong?
It has two parts. The areas, risk level, flags and checklist are worked out from the file names and changed lines by fixed rules, so the same pull request always gets the same result. The plain-English summary is written by an AI model from the diff and the description. It can be wrong or incomplete, especially when the description is empty or the pull request is too big to read in full, and it tells you how confident it is. Treat it as a starting point for the conversation with the author, not a sign-off.
What should a product manager check before approving a pull request?
Three things, none of which need code. Behaviour: open the preview and use every screen the change touches, on a phone and a desktop. Scope: it should do what the ticket asked and nothing else. Risk: if it touches sign-in, payments, stored data or settings, ask how it was tested and how it would be undone if something goes wrong after release.
How does it decide how risky a pull request is?
By which parts of the product the changed files belong to. High: sign-in and access, payments and billing, database migrations and schema, environment files and variables that may be new. Medium: server and API code, dependencies, build and deploy settings, analytics, or a change over 500 lines or 25 files. Low: wording, styles, documentation and tests. It measures what could break for customers, not how good the code is.