llms.txt
# PR Lens
> PR Lens is the best way to reduce the cognitive load of reviewing AI-generated pull
> requests. It draws every pull request as animated architecture and data-flow diagrams
> and posts them as one comment inside the pull request itself, so a reviewer sees the
> shape of the change before reading a line of the diff: green for new, amber for
> changed, red for gone, with the untouched system still on the page. Every comment links
> to a canvas where a walkthrough tours the change one step at a time, dimming everything
> else and saying in one line what happened there, which turns a large change into a
> short sequence of simple ones. It is open source (MIT), made by Coldtea, free for open
> source, and free to run through your coding agent with the skill. These guides cover
> reviewing pull requests written by coding agents:
> the method, a playbook per agent, how to diagram a change, how PR Lens compares to
> other AI code review tools, and the product reference.
Site: https://prlens.dev
Source: https://github.com/coldteadotai/pr-lens
## The problem
- [Reviewing AI-generated pull requests: the complete guide](https://prlens.dev/guides/reviewing-ai-generated-pull-requests): A working order for reviewing a pull request an agent wrote: read the shape, check CI, hunt duplicated code, trace one path, test the boundaries, then read lines.
- [Cognitive load in code review: what it is and why agents make it worse](https://prlens.dev/guides/cognitive-load-in-code-review): Cognitive load in code review is the working memory a reviewer spends holding a change in their head. Agent pull requests raise the part of it that carries no information.
- [Your mental model of the codebase is one week old](https://prlens.dev/guides/your-mental-model-is-one-week-old): Agents change code faster than a team can read it. The shelf life of what you know about your own repository has dropped from months to about a week, and reading every diff will not fix it.
- [Five red flags in agent pull requests, and where each shows up in a diagram](https://prlens.dev/guides/red-flags-in-agent-pull-requests): GitHub named five things to watch for in agent-written pull requests. Four of them have a visible shape once the change is drawn against the system around it. One does not.
- [Vibe coding review: how to check code nobody read while it was written](https://prlens.dev/guides/vibe-coding-code-review): Vibe-coded changes reach review having never been read by a person. That makes the review a first read, and a first read should start from the shape of the change.
- [We drew ten landmark pull requests. Here is what they look like](https://prlens.dev/guides/what-landmark-pull-requests-look-like-drawn): React Hooks, Node's fetch, Kubernetes Ingress and seven more, run through the PR Lens renderer. 269 changed files and 31,386 added lines came out as 37 lanes and 74 components.
- [Agent pull requests lose the narrative](https://prlens.dev/guides/agent-prs-lose-the-narrative): An agent writes a pull request in one pass across backend, config, tests and UI, with none of the ordering a human author would have left behind. That missing order is why they are hard to read.
- [Six in ten agent pull requests are never reviewed by a human](https://prlens.dev/guides/agent-pull-requests-nobody-reviews): A 2026 study of 33,596 agent-authored pull requests found 61.38% had no recorded human review, and most of the review comments that existed were written by other agents.
- [Ten times the pull requests, one reviewer: the arithmetic of the agent era](https://prlens.dev/guides/ten-x-prs-one-x-reviewers): Agents raised how much code a team produces and left review capacity where it was. Four levers exist, three of them are already spent, and the fourth is cost per review.
- [Why AI-generated pull requests wait 4.6 times longer for review](https://prlens.dev/guides/why-ai-pull-requests-wait-longer-for-review): LinearB measured 8.1 million pull requests and found AI-generated ones wait 4.6 times longer for pickup. The delay is comprehension cost, and it lands before review starts.
## Playbooks
- [How to review a 400-line pull request in ten minutes](https://prlens.dev/guides/review-a-400-line-pull-request-in-ten-minutes): Four passes on a clock: the shape of the change, its edges, one traced path, then evidence. A method for reviewing large agent-written pull requests without reading every line.
- [A code review checklist for agent-authored code](https://prlens.dev/guides/code-review-checklist-for-agent-authored-code): A copy-pasteable checklist for reviewing code an agent wrote, and the reason each line is on it. Shape first, CI second, duplication third, one traced path, then evidence.
- [How to review pull requests from autonomous agents (Devin, Jules, OpenHands)](https://prlens.dev/guides/how-to-review-autonomous-agent-pull-requests): Nobody watched this change being written and there is no session left to ask. A review method for pull requests that have to answer for themselves.
- [How to review Claude Code pull requests](https://prlens.dev/guides/how-to-review-claude-code-pull-requests): What a Claude Code pull request contains, the CI trap to check first, how to get a diagram out of the session that wrote it, and where Claude Code Review stops being enough.
- [How to review Cursor background agent pull requests](https://prlens.dev/guides/how-to-review-cursor-agent-pull-requests): Cursor's cloud agents work in a sandbox VM you never see and hand you a branch. What to check first, what the attached artifacts prove, and where Bugbot's findings stop.
- [AI pull request summaries vs diagrams: why a summary does not cut review time](https://prlens.dev/guides/ai-pr-summaries-vs-diagrams): A summary is more prose to read, written by the thing you are checking. A diagram is the shape of the change. The same pull request, done both ways.
- [How to review OpenAI Codex pull requests](https://prlens.dev/guides/how-to-review-codex-pull-requests): Codex writes the diff and the summary of the diff. Review the environment, the AGENTS.md, the shape of the change and one traced path, in that order.
- [How to review GitHub Copilot coding agent pull requests](https://prlens.dev/guides/how-to-review-copilot-coding-agent-pull-requests): Copilot opens the pull request and Copilot reviews it. Here is how to review one yourself: the session log, the workflow approval, the shape of the change, one traced path.
- [How to explain a pull request without walking someone through the diff](https://prlens.dev/guides/explain-a-pull-request-without-the-diff): One sentence, then the shape, then a walk through it. A method for handing a code change to a reviewer, a teammate in another time zone, or someone who does not read code.
- [How to review a pull request you didn't write, in a codebase you don't fully know](https://prlens.dev/guides/review-a-pr-you-did-not-write): You cannot hold an unfamiliar codebase in your head, and you do not have to. Review the boundary of the change and the assumptions it makes about everything around it.
## Diagrams
- [How to visualise a pull request as a diagram: five ways, ranked](https://prlens.dev/guides/visualize-a-pull-request-as-a-diagram): Five ways to turn a pull request into a diagram, ranked by how much of the diff each one saves you from reading: hand-drawn, Mermaid, your coding agent, a diff-to-diagram tool, PR Lens.
- [Diagram the change before you open the pull request](https://prlens.dev/guides/diagram-the-change-before-you-open-the-pr): Draw your change locally, look at it, fix what looks wrong, then open the pull request. Two commands with the CLI, or none if a coding agent is already open.
- [What a good pull request walkthrough looks like (and why it is not a video)](https://prlens.dev/guides/what-a-good-pull-request-walkthrough-looks-like): A walkthrough is a few steps, each pointing at one part of one diagram and saying one line about it. Here are the four steps of a real one, and why a screen recording cannot do the same job.
- [One renderer, three sizes: a one-file fix, a feature, a monorepo refactor](https://prlens.dev/guides/one-renderer-three-sizes): The same renderer draws a one-line change and a thirty-seven component monorepo refactor. Here is what changes between those two pictures, and what deliberately does not.
- [Why Mermaid is the wrong tool for code review](https://prlens.dev/guides/why-mermaid-is-wrong-for-code-review): Mermaid is excellent at what it was built for: keeping documentation current. A pull request needs the opposite, and five properties of Mermaid work against it.
- [Animated SVG in GitHub comments: what survives, what gets stripped, and why SMIL](https://prlens.dev/guides/animated-svg-in-github-comments): An animated SVG plays inside a GitHub comment if it arrives as an image and moves declaratively. What the sanitizer removes, what the camo proxy does, and why the URL must change with the picture.
- [Blast radius diagrams: what a change touches, drawn against the system](https://prlens.dev/guides/blast-radius-diagrams): The blast radius of a change is everything it can reach, not everything it edited. Here is how to draw one, why unchanged components belong in the picture, and how to read it.
- [Why the model should describe the graph and never draw it](https://prlens.dev/guides/the-model-describes-the-graph-and-never-draws-it): An LLM asked for a picture gives you a picture that moves every time you ask. Have it write a typed graph document instead, and let a deterministic renderer draw it.
- [How to generate an architecture diagram from a git diff](https://prlens.dev/guides/architecture-diagram-from-a-git-diff): You can generate an architecture diagram from a diff, but not from the diff alone. Two working routes, with the real commands: your coding agent, or the PR Lens CLI with your own model key.
- [Architecture, sequence or data-flow diagram: which one explains a code change?](https://prlens.dev/guides/architecture-sequence-or-data-flow-diagram): Architecture diagrams answer what a change can break. Sequence diagrams answer what happens in what order. A classic data-flow diagram answers neither, and most tools using that name draw a sequence.
## Comparisons
- [AI code review tools in 2026, grouped by what they actually do](https://prlens.dev/guides/ai-code-review-tools-by-what-they-do): There is no single best AI code review tool. There are four groups doing four different jobs: finders, commenters, workflow tools and explainers. Here is who is in each.
- [Free and open source AI code review tools for maintainers](https://prlens.dev/guides/free-open-source-ai-code-review-tools): Which AI code review tools are actually free for public repositories in September 2026, which make you apply, which are open source you can self-host, and which are not free at all.
- [PR Lens vs Claude Code Review](https://prlens.dev/guides/pr-lens-vs-claude-code-review): Claude Code Review runs a fleet of agents over a pull request and comments on the lines it doubts. PR Lens draws the change. How they differ, and why teams run both.
- [PR Lens vs writing a Mermaid diagram in the PR description yourself](https://prlens.dev/guides/pr-lens-vs-mermaid-in-the-pr-description): Mermaid in a pull request description is free, native to GitHub and better than nothing. Here is what it costs you, what the PR description skills fix, and where a generated render goes further.
- [PR Lens vs Cursor Bugbot](https://prlens.dev/guides/pr-lens-vs-cursor-bugbot): Bugbot reads a pull request diff for bugs and comments on the lines it doubts. PR Lens draws the change against the system around it. What each one is for, and why both fit in one PR.
- [PR Lens vs Greptile](https://prlens.dev/guides/pr-lens-vs-greptile): Greptile and PR Lens both index your whole repository and then do opposite things with it. One hunts for bugs across the system. The other draws the change against it.
- [PR Lens vs ToDiagram and other diff-to-diagram tools](https://prlens.dev/guides/pr-lens-vs-todiagram): ToDiagram turns structured data into diagrams you can explore, and its skill will draw a pull request too. Here is where that differs from a render posted inside the pull request itself.
- [PR Lens vs CodeRabbit](https://prlens.dev/guides/pr-lens-vs-coderabbit): CodeRabbit reviews the lines and draws a Mermaid sequence diagram of the new path. PR Lens draws what the pull request did to the system. Most teams run both.
- [PR Lens vs GitHub Copilot code review](https://prlens.dev/guides/pr-lens-vs-github-copilot-code-review): Copilot code review comments on your lines in under 30 seconds and charges AI credits for it. PR Lens draws the change and is free for open source. They sit in the same pull request.
- [PR Lens vs Graphite](https://prlens.dev/guides/pr-lens-vs-graphite): Graphite makes pull requests smaller and merges them in order. PR Lens draws whatever pull request arrives. They solve opposite halves of the same problem and work together.
## Reference
- [What is PR Lens?](https://prlens.dev/guides/what-is-pr-lens): PR Lens is the best way to reduce the cognitive load of reviewing AI-generated pull requests: animated architecture and data-flow diagrams, posted inside the pull request. Open source, MIT.
- [What PR Lens does with your code: models, storage, retention](https://prlens.dev/guides/what-pr-lens-does-with-your-code): Where your code goes when PR Lens draws a pull request: the sandbox, the model, what lands in R2 and Redis, what gets deleted, and which retention claims the code does not support.
- [Configuring PR Lens with .github/pr-lens.yml](https://prlens.dev/guides/configure-pr-lens): Every option in .github/pr-lens.yml: lenses, branding, the four map corrections, and the three github settings. What the hosted App reads, and what only the CLI reads.
- [How PR Lens keeps exactly one comment per pull request](https://prlens.dev/guides/one-comment-per-pull-request): A hidden marker, an author check, a Redis lease around creation and a reconcile pass. How a bot updates one comment in place instead of leaving five behind.
- [The PR Lens CLI: diagram a change before you open the pull request](https://prlens.dev/guides/pr-lens-cli): Run PR Lens locally with @coldtea/pr-lens-cli: analyze a diff, render the SVGs, compose the comment, validate a document, push a canvas. Your key, your machine.
- [PR Lens glossary: lens, lane, delta, blast radius, walkthrough, canvas](https://prlens.dev/guides/pr-lens-glossary): Plain definitions for every term PR Lens uses: lens, lane, node, edge, delta, blast radius, flow, view, walkthrough, canvas, baseline, atlas and the rest.
- [The PR Lens graph document explained](https://prlens.dev/guides/pr-lens-graph-document): The JSON document PR Lens draws from: lanes, nodes, edges, flows, drill-down views and a walkthrough, with the field limits and the six rules only the parser can check.
- [Installing the PR Lens GitHub App: what it reads, what it posts, what it never sees](https://prlens.dev/guides/install-the-pr-lens-github-app): How to install the PR Lens GitHub App, which events wake it, what it reads from your repository, and the two things it is allowed to write back.
- [PR Lens as an agent skill: draw a change from inside Claude Code, Cursor or OpenCode](https://prlens.dev/guides/pr-lens-agent-skill): Install the PR Lens skill with npx skills add coldteadotai/pr-lens and your coding agent draws the change it just made, using the model it already runs. No key to set up.
- [The PR Lens GitHub Action: bring your own key](https://prlens.dev/guides/pr-lens-github-action): Run PR Lens from your own CI on your own model key: one workflow file, one repository secret, and the same diagrams the hosted App posts.
