It diagrams your pull request so you don't have to

What it does

PR Lens analyzes a pull request and renders it as SVG diagrams embedded directly in the PR comment. It maps the change as an architecture diagram—showing touched components against the wider system, color-coding green for new, amber for changed, and red for deleted—and as an animated sequence diagram that walks through data flow one step at a time. The comment nests scoped views inside collapsible sections, and every diagram links to an interactive canvas for panning, zooming, and light or dark themes.

The interesting bit

Rather than calling out to a black-box service, the tool splits the work into a graph document that describes the change and a validator that enforces the schema before rendering. That design lets coding agents generate their own diagrams without spending an extra provider key: the agent already understands the diff, writes the document, and iterates against the validator until the contract is satisfied. It is a neat separation between “know what changed” and “draw it consistently.”

Key highlights

• Blast-radius architecture: Components involved in the PR and the calls between them, with color-coded deltas.
• Animated data-flow walkthroughs: A dot traces each step in order; playable in the comment or on the interactive canvas.
• Nested drill-down: The comment uses <details> blocks to separate the full blast radius, the new path, and retired code.
• Agent-native: Runs as a GitHub App, Action, or CLI, and offers a skill mode where agents write and validate the graph document locally.
• Theme-aware: Diagrams ship as paired SVGs that automatically match the reader’s GitHub light or dark preference.

Caveats

• The README notes the underlying model can rename things between runs, and the project supplies a YAML overlay for pinning component names, exclusions, and lane groupings.
• Agent mode requires manually satisfying a schema contract and iterating validation, which is more hands-on than the turnkey GitHub App.

Verdict

Teams juggling large diffs or monorepo refactors will get the most value from seeing blast radius before diving into files. Solo developers on small, stable codebases likely do not need an automated diagrammer in their review loop.