AI PR Analyzer

Review a large change the way it was written, not the way it was filed.

A pull request of fifty files arrives as an alphabetical list. AI PR Analyzer orders those files into the flow a reader should follow, opens each one at the change itself, and draws a diagram of what the change actually does — so you can understand a branch before you start reading it.

When one feature spans several pull requests in different repositories — a service, a library, the pipelines that use it — it reviews them together as one change, with a map of where they meet and a check that they fit.

Built for reviewing AI-written changes, where the volume is high and the reviewer has no memory of writing any of it.

What it looks like

Both samples below are a made-up "submit an order" change — no real code — just to show the shape of what you get.

The map. Each box is a step in the flow, numbered in reading order and marked new, changed, or left plain when untouched, so you can see exactly where a branch reached. In the extension the boxes are clickable and open the file behind them:

Green is new, amber is changed, plain is untouched.

The read-through. The book icon narrates the same change end to end, in the order it runs, with the values moving through it, and ends on what an operator would see before and after:

What it does

Orders the change as a flow. Files are placed in the order execution reaches them, starting at the entry point rather than at whatever sorts first. Each step is named for what happens there — "Setup task entry", "Resolve the capacity profile" — not for its file name.

Walks changes, not files. Next and Previous move through the hunks inside a file and then carry on into the next file, so a fifty-file change is one continuous read.

Draws the change. A diagram of how the code works at runtime, with every node marked as new, changed, or existing, so you can see where this branch touched the flow. Numbered, so you can point at a box in review. Clicking a node opens the file behind it.

Explains a diff in context. @pr in chat explains the change on screen, and can read the rest of the repository to do it — the definition of a method that the diff calls but does not contain. Answers lead with the point and carry a worked example using values from your code; where a flag has only a few states, every state is shown, including the null of a nullable bool.

Explains one change where it sits. Every changed region carries an Explain this link above it. Pressing it answers that region alone, in a comment anchored there, so the explanation is beside the code rather than in another panel. Nothing is generated until you ask: a change of any size would otherwise be a long wait for paragraphs you did not want.

VS Code ships diffEditor.codeLens turned off, so these links do not appear in a diff until it is on. You are offered it the first time a diff opens; to turn it on later, set diffEditor.codeLens to true.

Reads the whole change end to end. The book icon opens a read-through: what the change accomplishes, then each step of the flow in the order it runs, with the values moving through it. Every heading opens that file's diff, so you can read the account and drop into the code where it matters. It ends with what an operator would find before and after the change. Written once per review, with Write it again for another pass, and Stop while it is thinking.

Works before you push. The default source is your branch against its merge base, including uncommitted work. You do not need a pull request, or even a commit.

Groups files the way the repository does. The Files view lists changes in reading order by default, numbered to match the flow. The tree icon switches to a folder view that reads like the pull request page — the repository's own shape, sorted alphabetically — for when you want to find a file by where it lives rather than when it runs.

Shows the git it ran. Every git command is recorded — what ran, where, how long it took, and what git said when it failed — reachable from the terminal icon or Show the git commands. When a checkout or fetch fails, the reason is a line you can read and reproduce, not a mystery.

Checks intent against the change. Map intent to evidence reads what the change set out to do — a pull request's description and its linked work items, or a branch's commit subjects — and lays each intent beside the files that implement it and the tests that cover it, so a promise made with no code or no test behind it is visible rather than buried.

Flags what changed with no test. A production file altered without a matching test change is marked no test in the Files list, so the gap is on screen before you open anything.

Shows what an answer read. Every @pr answer ends with the files it opened beyond the diff, so a grounded explanation reads differently from a guess.

Keeps count of what you have seen. The status bar tracks how many of the changed files you have opened, and how many were left out, so a large review has a finish line.

Remembers where you were. Reopen the same change and it resumes at the file you left, with the files you had already read still marked — nothing is re-read from the top.

Adds a note to the pull request. Add a review note posts a comment back to the pull request, anchored to the file and line on screen, so a finding made here lands in the review everyone else is reading.

Reviews a feature across pull requests. Paste one pull request and the others belonging to the same work are found for you — by a shared AB# work item, branch, or link, in any project of the organisation — then read together as one change: one row per repository, in the order the feature runs. The map draws one box per repository with the links between them labelled, and Check the pull requests fit together reports a merge order and anything that does not line up, such as a name one side removes that another still calls. See Reviewing a feature across pull requests.

Requirements

• VS Code 1.95 or later
• GitHub Copilot, signed in — the extension uses your existing subscription
• git on the path

A language server for the repository's language is optional. It sharpens the reference graph when it is running, and is skipped when it is not.

In a workspace you have not trusted, the diff and its navigation still work; reading the wider repository for @pr, the diagram, the read-through, and the intent map waits until you trust it.

Reviewing a branch needs no account at all. Reviewing a pull request needs access to Azure DevOps, either way round:

• Your VS Code account, if it can reach the organisation. Nothing to type.
• A personal access token, for organisations account sign-in cannot reach. Create one under User settings → Personal access tokens with Code (read), then run AI PR Analyzer: Sign in to Azure DevOps and choose the token. It is kept in VS Code's secret storage, never in settings, and Forget the stored Azure DevOps token removes it.

Both dev.azure.com and the older *.visualstudio.com hosts are understood.

Getting started

Three ways in. None asks you to prepare anything by hand.

A pull request, from nothing. Run AI PR Analyzer: Review a pull request by URL and paste an Azure DevOps link. That is the whole setup: the repository does not have to be open, checked out, or even cloned. A missing clone is offered, and the pull request is checked out into a worktree of its own, removed when you move on. Your branch is never touched.

A branch you are already on. Open the repository and run AI PR Analyzer: Review this branch, or press the button in the AI PR Analyzer view. Uncommitted work is included, so there is nothing to push or even commit first.

A feature spread over several pull requests. Run AI PR Analyzer: Review a feature across pull requests… and paste any one of them. The rest are offered as a checklist, each with the reason it was matched; untick any that do not belong. Details are in Reviewing a feature across pull requests.

A workspace holding several repositories. "This branch" is the one checked out in the repository of the file on screen. To switch without opening a file, run AI PR Analyzer: Review a branch in another repository… — the equivalent of cd-ing into it. It lists every repository in the workspace with its current branch, including repositories nested one level inside a workspace folder, and Browse… reaches any other folder on disk. Refresh and Set the branch to compare against stay on the repository you picked.

Then, either way:

1. Step through with F7 and Shift+F7, or the chevrons on the Files view.
2. Press the map icon to draw the diagram, or the book icon to read the change end to end.
3. Press Explain this above any change, or ask @pr /explain in chat about what is on screen.

To review something else, pick Review a pull request by URL, Review this branch, or Review a branch in another repository… from the … menu at the top of the Files view. The new review replaces the old one, and the previous worktree is removed. The heading beside Files names what you are reading.

To read the whole repository rather than only the changed files, a clone is looked for in three places, cheapest first:

1. Your open workspace folders.
2. <folder>/<repository> for each path in prAnalyzer.repositorySearchPaths, and beside each open folder. This is an exact check, not a search: no directory is listed, and nothing matches by accident.
3. Otherwise you are offered Clone it, Locate it — pick the folder yourself, and where you keep clones is remembered — or Continue without.

The pull request is then checked out into a temporary worktree, which is removed when you move on. Continuing without a clone still works, with only the changed files.

Reviewing a feature across pull requests

A feature often lands as several pull requests in different repositories — a service, a library, the pipelines that use it, a deployment package. Each can look right on its own while the feature is broken where they meet. This reviews them together, as one change.

Run AI PR Analyzer: Review a feature across pull requests…, or press its button in the AI PR Analyzer view, and paste one or more pull request URLs. To hide it, turn off prAnalyzer.featureReview.

1. The rest are found for you. Every active pull request in the organisation — all projects, since a feature can span them — is checked for the same AB# work item in its title or description, the same source branch, a formal link from the work item, or a link to or from the one you pasted. You get a checklist with the reason for each; untick any that do not belong.
2. One review, in the order it runs. Each pull request is read and checked out as usual, and the Files view shows one row per repository with its files beneath, numbered 1 to n across the whole feature. The repositories are read in execution order — a caller before what it calls, so a service comes before the DAG it triggers, and the DAG before the library it imports — with documentation last. Where the code does not say which calls which, the repository that looks like where the flow starts comes first. F7, Explain, @pr chat, notes and the read-through all work across the feature, and the model's lookups reach every repository. The merge order in the fit report is the other way round: what is depended on first.
3. A map of how they connect. The map draws one box per repository, with the arrows between them labelled by what crosses: the DAG id one triggers, the module one imports, the package version one pins. Those links are found in the code first — imports, pinned versions, names one side declares and another calls, and identifier strings such as DAG ids and config keys that both use — and given to the model as facts rather than left for it to guess.
4. Checks that they fit. Check the pull requests fit together, on the Files view's toolbar, opens a report: a suggested merge order and why, and anything that does not line up — a name one side removes that another still calls, a pinned version the library does not publish, a string one side stops using while another still does, pull requests merging into different branches. A summary appears when the feature loads.
5. Share it on every pull request. Post to PR on the map posts it to each of the feature's pull requests, each with a list of the others, so whoever opens any of them sees the whole.

Add a note posts to the pull request that owns the file on screen. The links it finds are heuristics: they are shown with the file each was seen in, so they can be checked.

Commands

Settings

Moving around the diagram

The steps of a drawn map are numbered in the order they sit on screen — box by box from the top, and within a box row by row — so 1, 2, 3 read straight down however the layout placed them. The file map keeps the numbers of the Files list.

When you are reviewing a pull request, Post to PR on the map's toolbar posts the whole map — not just the part on screen — as a new comment on the pull request. The map is uploaded as a PNG attachment, since a detailed map can exceed the description's length limit and comments do not reliably render mermaid. A comment shrinks the image to its width, so the image links to the full-size file, and Open the full-size map beneath it opens it on its own, where the browser zooms it. A link to AI PR Analyzer on the Marketplace follows, so whoever reads the comment can draw a map of their own. You are asked to confirm first. The button is not shown when reviewing a branch. For a feature, the map is posted to every one of its pull requests, each listing the others.

When git goes wrong

Every git command is recorded, with the folder it ran in, how long it took, and what git said when it failed. Open it from the toolbar button above the Files list, or run AI PR Analyzer: Show the git commands. Each line is written the way you would type it, so a failure can be reproduced in a terminal.

What it sends, and where

The extension talks to two services, both with your existing credentials:

• GitHub Copilot, for ordering, the diagram, @pr chat, the read-through, and the intent map. It receives the changed files, a digest of what changed in them, whatever files the model then asks to read, and — for the intent map — the pull request's description and linked work item titles, or the branch's commit subjects.
• Azure DevOps, when you review a pull request by URL, to fetch that pull request's files and, if you map its intent, its description and linked work items; when you add a review note, to post that comment back to the pull request; and when you press Post to PR on the map, to upload the map as an image attachment and post a comment showing it. Reviewing a feature also lists the active pull requests in the organisation's projects and reads the work items they mention, to find the related ones. VS Code's own Microsoft sign-in is used, or a token you supplied.

Nothing is sent anywhere else, and nothing is written outside VS Code's own storage.

How the ordering and the diagram are produced

Ordering is a model's judgement, given evidence: which files declare which symbols, and which files reference them. Its answer is reconciled against the real file list, so an invented path is discarded and an omitted one is appended — you always see every file exactly once.

The diagram is drawn by a model that is given the added and removed declarations and the rewritten conditions from each file, and can read the repository to fill in what the digest does not show. If it returns something unparseable, a plain file map is shown instead and the reason is reported rather than hidden.

Both cost one Copilot request each. Set prAnalyzer.ordering to references to skip the first.

Known limitations

• A pull request from a repository that cannot be found or cloned is only the files it changed: the model cannot read a caller or search the wider repository, and the ordering has less to go on.
• Cloning needs git to authenticate without prompting. No terminal is attached, so if your credential helper wants input the clone fails rather than hangs. Clone the repository once from a terminal and it will be found from then on.
• A checked-out pull request is not in the workspace, so the language server does not index it. Files and search work; go-to-definition accuracy comes from your own checkout.
• Binary files are skipped, and reported as skipped.
• Only Azure DevOps pull request URLs are understood.
• Renames are detected but lightly tested.
• A feature's related pull requests are found by matching, not by a formal link: a shared AB# work item in the title or description, the same source branch, or a link between them. One that shares none of these is missed — paste it as well — and one that shares a work item by coincidence is offered; untick it.
• The links between a feature's repositories are found by reading the changed code — imports, pinned versions, shared names and identifier strings. They are shown with the file each was seen in so they can be checked, and a link made only through configuration outside the change is not seen.
• Drawing the diagram costs a model request. A drawn map is kept per commit, so reopening it — even after restarting VS Code — is instant and free. A new commit, or Redraw, draws it again and costs another request.

Installing it

It uses your own GitHub Copilot sign-in — there is nothing else to set up.

From the Marketplace. Search AI PR Analyzer in the Extensions view, or open the listing and press Install. From a terminal:

code --install-extension rajeshvijay.pr-analyzer

A freshly published version can take a while to surface in search; typing @id:rajeshvijay.pr-analyzer in the Extensions box finds it straight away. Marketplace installs update themselves.

From a build. Every push to main publishes pr-analyzer-vsix as a build artifact, and each release tag attaches the same .vsix. Download it and run:

code --install-extension pr-analyzer-<version>.vsix

From source.

cd PR-Analyzer-VSCode
npm ci
npm run package        # writes dist/pr-analyzer-<version>.vsix
code --install-extension dist/pr-analyzer-<version>.vsix

Then reload VS Code. Working over Remote-SSH or WSL? Install it in the remote, since that is where git and the repository live.

A sideloaded .vsix does not auto-update, so bump version in package.json when you publish a build worth taking, and tell people to reinstall — or install from the Marketplace, which updates itself.

License

MIT — see LICENSE.

Development

npm install
npm run compile     # both bundles: extension host and diagram webview
npm run typecheck   # extension and webview are typechecked separately
npm test

Press F5 to launch an Extension Development Host.

Logic worth testing lives outside any module that imports vscode, because those cannot be loaded under the test runner. That is why ordering, diffing, digests and prompts are plain modules with the editor kept at the edges.

The diagram prompt and the digest that feeds it are pinned by tests/diagram-locked.test.ts. Prompt quality cannot be read off the code, so an accidental edit would otherwise change the output silently. Changing them is fine — update the test in the same commit, and check the result against a real pull request first.