Robin

How Robin Reviews a PR (Behind the Scenes)

A step-by-step look at what Robin actually does when it reviews a pull request — from fetching the diff to posting inline comments and a summary.

When Robin reviews a pull request, it runs a short, transparent pipeline: it fetches the PR’s diff, filters out noise, caps the size so the request stays sane, sends the result to the LLM endpoint you configured, parses the model’s findings, and posts them back as inline comments plus a summary — all inside GitHub Actions, with your code going only to your chosen endpoint. There’s no hidden service and no magic. Because Robin is an open-source GitHub Action, every step is something you can read in the source. This post walks through what actually happens between “PR opened” and “review posted.”

Key Takeaways

  • Robin runs entirely in your GitHub Actions runner; your diff goes only to the LLM endpoint you configure.
  • The pipeline is: fetch diff → filter → size-cap → call the model → parse findings → post inline comments + summary.
  • Large diffs are truncated to a configurable character limit so requests stay within model limits.
  • Inline comments are capped (configurable); any extra findings go in the review body, not dropped silently.

Step 1: The Trigger

Robin runs as a GitHub Action. It reviews automatically when a pull request opens, and on demand when someone comments /robin (or /review). Because it’s an Action, it executes inside your repository’s CI runner using the secrets you’ve set — LLM_API_KEY, LLM_BASE_URL, and MODEL — so there’s no external Robin service receiving anything. (On pull requests from forks, GitHub withholds secrets for security, so those are triggered manually by a maintainer.)

Step 2: Fetching and Filtering the Diff

Once triggered, Robin gets the pull request’s diff — the exact lines added, removed, and modified. But a raw diff often contains material that’s noise for review: lockfiles, generated output, vendored code, binary blobs. Robin filters the diff so the model spends its attention on the changes that actually merit review rather than on a 2,000-line lockfile churn.

This filtering step is one reason review quality holds up: feeding a model everything, including generated artifacts, produces lower-signal comments. Trimming to the meaningful changes keeps the review focused.

Step 3: Size-Capping

Models have input limits, and very large diffs are both expensive and prone to degraded output. Robin caps the diff at a configurable character limit (50,000 characters by default) and truncates beyond it. If a PR is enormous, Robin reviews up to the cap rather than failing outright — and the practical lesson it reinforces is the one every reviewer gives: keep PRs small. A focused diff gets a focused, complete review; a giant one gets truncated for any reviewer, human or AI.

Step 4: Calling the Model

Robin composes a prompt around the filtered diff and sends it to the endpoint defined by your LLM_BASE_URL and MODEL. This is the only point where your code leaves the runner, and it goes exactly where you pointed it — OpenAI, Anthropic via a compatible proxy, a free model on OpenRouter, or a self-hosted model (set the API key to ollama for a local Ollama endpoint). Robin uses a generous request timeout by default because large diffs on slower models can take a while; you can tune it if needed.

Because the model is yours to choose, the review’s depth is your decision. A free model gives solid first-pass coverage; a frontier model reasons more deeply about complex logic. Swapping between them is a one-line change to the MODEL secret.

Step 5: Parsing Findings and Posting

The model returns its analysis, and Robin parses it into structured findings — each tied to a severity (High, Medium, Low, or Suggestion) and, where applicable, a specific line. Robin then posts them through GitHub’s review API: inline comments on the relevant lines, plus a short summary of the change in the review body.

There’s a deliberate cap on how many inline comments Robin posts, so a noisy PR doesn’t get buried under hundreds of inline threads. Crucially, findings beyond that cap aren’t dropped silently — they go into the review body, so you still see them without the inline clutter. Optionally, Robin can be configured to fail the check when high-severity issues are found (fail-on-high), though it’s off by default — keeping review advisory rather than a hard merge block unless you opt in.

Why the Transparency Matters

Every step above is readable in Robin’s source. That’s not just an open-source nicety — for a tool whose entire job is to read your code, being able to see exactly how it fetches, filters, sends, and posts is the difference between trusting a black box and verifying a process. You can confirm the diff goes only to your endpoint, see how filtering works, and adjust the caps to fit your repo.

In our experience maintaining Robin, the teams most interested in the behind-the-scenes flow are usually the ones evaluating it for sensitive codebases. The answer that satisfies them isn’t a marketing claim about privacy — it’s that they can read the few hundred lines that do the work and see for themselves that there’s no hidden hop.

Frequently Asked Questions

Where does my code go when Robin reviews a PR?

Only to the LLM endpoint you configure via LLM_BASE_URL. Robin runs in your GitHub Actions runner and has no service of its own in the path. If you point it at a self-hosted model, the diff never leaves your network.

What happens if my PR is too big?

Robin caps the diff at a configurable character limit (50,000 by default) and truncates beyond it, reviewing up to the cap rather than failing. The practical fix is smaller PRs, which every reviewer — human or AI — handles better.

Does Robin block my merge if it finds problems?

Only if you opt in. By default Robin is advisory: it posts comments and a summary but doesn’t fail the check. You can enable fail-on-high to fail when high-severity issues are found, but the default keeps the merge decision human.

Where to Go From Here

Now that you’ve seen the pipeline, the Robin documentation covers each configurable piece — diff size, comment caps, filters, and the fail-on-high option. To see how this open, in-your-runner approach compares to hosted reviewers, the Robin homepage lays out the bring-your-own-key model and what makes it different.