pr-lens

PR Lens

Understand a pull request, any codebase, or software visually, before you read a line of code PR Lens draws every pull request as animated architecture and data-flow diagrams, posted as a comment inside the pull request itself. For your coding agents, leverage it for understanding any codebase or code change with a live canvas of animated explainers

Install the GitHub App  ·  Install the Skill

Also runs on GitLab and Bitbucket

Free for open source   ·   Or have your coding agent draw it: npx skills add coldteadotai/pr-lens

Features

Not Mermaid, better

We built a custom renderer from scratch. It draws rich animated visuals, reduces cognitive overload, represents code additions, removals and changes and still works for representing very large systems

Architecture blast radius

The diagram shows the parts of your system that the code change touches, drawn against the system around it: the components involved, and the calls that run between them.

Colors show what changed: green is new, amber is changed, and red is removed.

Intuitive Data flow

Understand how data flows through your any code change or codebase. The diagram plays the steps of the change in order with a moving dot one step at a time

See the payload on every data flow

Click any arrow to see the data it carries. A panel opens next to the diagram with the request and the response. Each one shows either the expected shape or a sample. New fields are green and removed fields are red, the same colors the diagram uses.

Zoom in without leaving the page

The comment has folding sections (``) that you can open and close. Each one has its own diagram for one part of the change. The whole change is on top. Below it is the new path, and then what was removed.

Interactive canvas

Every comment or drawing can link to an interactive canvas. It has the same diagrams at full size. You can move around, zoom, and switch between a light and a dark theme. A big change gets all the room it needs instead of squeezing into a narrow comment or static image.

Walk through the change

PR Lens ships with animated explainers called walkthroughs. Walkthroughs let you explore a system or code change step by step, without overwhelm. Start a walkthrough by pressing play on the canvas, or press W.

Your agent, live on the canvas

Ask your local coding agent to connect to a canvas. Then use it to understand any codebase or code change. You can ask follow-up questions, zoom into any part of the diagram, or drag across a few cards and ask your agent about them. Watch it interact live with the canvas!

From one card to a whole monorepo

Every size of change uses the same look: lanes, cards, colors for what changed, and paths you can follow with your eyes.

For what it's worth, you should not open a pull request this big.

Light or dark theme

With the GitHub App, every diagram comes in a light and a dark version. GitHub shows the one that matches the reader's theme. You can also draw either theme on your own computer with your coding agent.

GitHub, GitLab and Bitbucket

PR Lens works on all three. On GitHub, install the App. On GitLab, add the CI/CD component to your pipeline. On Bitbucket, add the pipe.

Set it up for GitLab or Bitbucket

Hall of Fame

We ran the pull requests behind React Hooks, Node fetch and Kubernetes Ingress through PR Lens. They were drawn with the same renderer and the same format as the diagrams above.

react/react#13968 · 36 files · +5,868/−130 · 5 lanes. Hooks are added behind a feature flag.

nodejs/node#41749 · 16 files · +8,076/−3 · 5 lanes. fetch, Request, Response and Headers are added to Node itself.

kubernetes/kubernetes#14175 · 8 files · +766/−0 · 4 lanes. The first Ingress type, for L7 load balancing.

Seven more · Vue, Rust, Tokio, Neovim, Django, webpack, vLLM

vuejs/core#2532 · 11 files · +1,081/−670 · 3 lanes. <script setup> and the first version of ref sugar.

rust-lang/rust#31954 · 26 files · +369/−16 · 4 lanes. The ? operator, a short way to write try! that you can chain.

tokio-rs/tokio#1657 · 100 files · +7,408/−6,795 · 3 lanes. The work-stealing pool, rebuilt so the scheduler does less extra work.

neovim/neovim#11336 · 15 files · +5,556/−1 · 3 lanes. The LSP client moves into Neovim itself.

django/django#11209 · 38 files · +931/−42 · 5 lanes. An ASGI handler, and a request context that is safe to use with coroutines.

webpack/webpack#10440 · 13 files · +567/−5 · 5 lanes. ContainerPlugin, which brought module federation with it.

vllm-project/vllm#1348 · 6 files · +764/−139 · 3 lanes. PagedAttention V2 and its sequence-level parallelism.

Open the Hall of Fame. Every diagram there is live.

Configuration

Add a .github/pr-lens.yml file to change how PR Lens works. GitLab and Bitbucket have no .github/ folder, so there you can use .gitlab/pr-lens.yml or a pr-lens.yml at the top of the repo. They work the same way. The configuration reference lists every setting, its default, and examples.

Fix names and mistakes

When you draw with the CLI, put your fixes in .github/pr-lens.yml. Don't edit the SVG files it makes:

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

These fixes sit on top of what the model finds. They keep working as the code changes, even when the model names things differently from one run to the next. You can rename things, leave files out, pin cards to a lane, and group things together. See packages/cli for all of it.

Oth