What is PR Lens?

PR Lens is the best way to reduce the cognitive load of reviewing AI-generated pull requests. It draws a pull request as animated architecture and data-flow diagrams and posts them as one comment inside the pull request itself, so you see the shape of the change before you read a line of the diff. Coldtea makes it. It is MIT licensed, open source at github.com/coldteadotai/pr-lens, and free for open source. There are four ways to run it: a GitHub App, a GitHub Action, a command line tool, and a skill your coding agent picks up. I built it because of a number. LinearB's 2026 benchmarks, drawn from 8.1 million pull requests across more than 4,800 organisations, found that AI-generated pull requests wait 4.6 times longer for a reviewer to pick them up.

That wait is not a staffing problem. The pull requests arrive faster than anyone can read them, and reading is the expensive part. LinearB measured AI-assisted pull requests at 408 changed lines at the 75th percentile against 157 for unassisted ones. Once a reviewer starts, AI pull requests actually finish faster, about 194 minutes against 252. The cost sits in the gap before anyone begins.

PR Lens attacks that gap. It gives you a picture of the change before you read a single line of it.

What PR Lens does to a pull request

A pull request opens. PR Lens reads the diff against the system around it and writes a graph document: lanes, nodes, edges, and an ordered flow if the change has a sequence worth animating. A renderer turns that document into SVGs. A bot comment goes up on the pull request carrying the diagrams, and it is rewritten on every push.

The comment opens with counts. Three new, one changed, one removed, across five files, at a named commit. Under that sits the architecture diagram. Under that, a <details> tree that drills into one part of the change at a time: the whole blast radius on top, then the new path, then what was retired.

Colour carries the delta. Green is new, amber is changed, red is gone, and a removed component is struck through where it used to sit. The parts of the system the change did not touch stay on the page in grey, because a diagram of only the changed nodes tells you nothing about what a change is near.

The two lenses

PR Lens has two, and the schema deliberately stops there.

The architecture lens draws blast radius. It shows the components the pull request touched, the system they sit in, and the calls that run between them, grouped into lanes: a runtime, a tier, a boundary, whatever mental model the change belongs to. It is not the folder tree.

The data-flow lens draws an ordered pipeline as an animated sequence. One dot crosses one arrow at a time, in the order the steps happen. A change that has no sequence gets no flow, and the comment says so rather than inventing one.

The words lane, delta, view and walkthrough all have exact meanings in the document. I wrote them down in the PR Lens glossary.

Four ways to run it

The GitHub App is the whole setup for most people. Install it at github.com/apps/coldtea-pr-lens, pick your repositories once, and every pull request opened in them is drawn and redrawn on each push. It runs on Gemini today, with no model key of yours involved. What it reads and what it posts is in installing the PR Lens GitHub App.

The GitHub Action runs the same pipeline in your own CI on a key you supply. It is a workflow file and one secret. The provider defaults to Gemini and also speaks OpenAI or any endpoint that answers /chat/completions, so OpenRouter, DeepSeek and a server of your own all work. The full workflow is in the PR Lens GitHub Action.

The agent skill teaches a coding agent to draw the change it just made. Your agent is already a model reading the diff, so it writes the graph document itself rather than paying a second model to describe a diff it understands. npx skills add coldteadotai/pr-lens installs it. See PR Lens as an agent skill.

The CLI is every step on your machine, one at a time: analyze, render, comment, validate, export, canvas. It is on npm as @coldtea/pr-lens-cli. The commands and their flags are in the PR Lens CLI.

The comment, the canvas and the walkthrough

Every comment links to a canvas at prlens.dev/c/<id>. That is the same diagrams at full size, with pan, zoom, and a light or dark theme, because a system with six lanes is several times wider than the roughly 830 pixels a GitHub comment gives you.

On the canvas, press play or hit W and the change tours itself. Each step dims everything else, lights the cards and routes it is about, and says in one line what happened there. Two steps minimum, twelve maximum, three to seven in practice. A step is a change, so its heading uses change words: added, removed, replaced, now, moved, split. A heading that could have been true before the pull request is not a change heading, and the skill teaches an agent to rewrite it.

Keeping exactly one comment alive across dozens of pushes is its own small engineering problem, and I wrote up how we solved it in how PR Lens keeps exactly one comment per pull request.

The model never draws

This is the design decision the rest of the product hangs off. A model reads the diff and writes a strongly typed JSON document. It never emits SVG, never picks a coordinate, never chooses a colour.

{
  "kind": "graph",
  "lenses": ["architecture", "data-flow"],
  "lanes": [{ "id": "api", "label": "API" }],
  "nodes": [
    {
      "id": "health-route",
      "label": "GET /health",
      "kind": "route",
      "delta": "modified",
      "lane": "api"
    }
  ]
}

That document is parsed against a schema that rejects unknown keys, checks that every edge joins declared nodes, and reports every problem it finds rather than only the first. Then the renderer draws it. The renderer has no dependency beyond that schema, measures text against an embedded table rather than a font engine, and emits the same bytes for the same document every time. Its output carries no JavaScript, which is why the animation still plays inside a GitHub comment where scripts are stripped.

Everything to the left of the document reasons about code. Everything to the right of it draws. The full field reference is in the PR Lens graph document explained.

PR Lens does not look for bugs

There is no findings lens. There is no field in the document for a bug, a risk, or a security note, and a document that invents one is rejected rather than quietly trimmed. That is a decision, not a gap.

Bug finders are a crowded and genuinely useful category. Copilot code review, Greptile, Cursor Bugbot and Claude Code Review all read a diff and tell you what might be wrong with it. They answer "is this correct". PR Lens answers one question: what does this pull request change? Run both. They sit in the same pull request without fighting.

What it costs

Free for open source. The repository is MIT, so the renderer, the schema, the CLI and the Action are yours to fork, vendor or run offline. And you can run it for free through your coding agent: the skill reasons with the model that agent already uses, so there is no key to set up and nothing to pay us.

If you run the Action or the CLI, you pay your model provider for the analysis call and nobody else. The key is read from the environment, never from a flag, and the diff goes to the provider you named and nowhere else. There is no PR Lens service in that path at all. What the hosted App stores, and where, is in what PR Lens does with your code.

Configuring it

One file, .github/pr-lens.yml, read from the pull request's head commit. It carries the lenses to render, the branding footer, whether the comment starts collapsed, and a map of corrections: renames, exclusions, lane pins, groupings.

schemaVersion: 0.1.0
map:
  rename:
    - match: services/legacy-mailer.ts
      to: Postmark sender
  exclude:
    - "**/*.test.ts"

Corrections are an overlay applied over fresh inference on every run, so a rename keeps holding as the code moves and the model names things differently between runs. Inference never writes back into the file. The options that exist, and only those, are listed in configuring PR Lens.

Where it came from

Coldtea builds developer tools, and we had the same problem everyone else has: agents writing more code than the team could read. The essay behind PR Lens argues that the one thing review cannot automate is building a shared mental model of the system, and that stale knowledge which used to be three months old is now one week old. Drawing the pull request moves the proxy higher, from reading lines to reading structure.

You can see the argument tested on changes nobody can accuse of being toy examples. The Hall of Fame at prlens.dev/gallery redraws landmark pull requests: React Hooks at 36 files and +5,868 lines, Node's fetch at 16 files and +8,076, the first Kubernetes Ingress type at 8 files and +766. Those ran through the renderer and the contract that draw a comment on an ordinary Tuesday.