PR Review

Agentic GitHub pull request review inside VS Code, powered by GitHub Copilot's language models via the Language Model API. The extension runs a tool-using review agent against your diff, shows results in a webview with per-comment checkboxes, and (optionally) submits the selected comments back to GitHub as a real PR review.

Works against github.com and GitHub Enterprise.

Features

Five entry points

Diff base

• Palette commands (current branch / another branch) diff against the configured prReview.baseBranch (default origin/master).
• PR right-click commands diff against the PR's actual base branch as reported by the GitHub API.

Review workflow

1. The agent receives a language-specific review template (see Templates) as its system prompt, plus the diff and changed-file list.
2. It explores the codebase using a limited tool set — readFile, listDir, grep, gitShow — and optionally linters / shell commands if you raise prReview.toolScope.
3. When finished, it calls a submitFindings tool with structured findings (severity, title, body, file, line, optional suggestedFix). That call terminates the agent loop.
4. The findings open in a webview. Each is checkboxed; you pick which to send. The proposed decision (APPROVE / COMMENT / REQUEST_CHANGES) is derived from severity but you can override it in a dropdown before submitting.
5. Submit posts a GitHub PR review via the REST API. Copy as markdown drops the same content on the clipboard for use elsewhere — useful when there's no open PR yet.

If the current branch has no open PR (or you're using one of the "review without an associated PR" paths), Submit is disabled with a hint; the rest of the panel works for local self-review.

Requirements

• VS Code with GitHub Copilot installed and signed in (provides the copilot vendor for vscode.lm.selectChatModels).
• git on PATH — the extension shells out for diff, fetch, worktree, and ref-aware reads.
• GitHub auth — uses VS Code's built-in github (or github-enterprise) authentication provider. You'll be prompted on first submit; the extension requests the repo scope.
• Optional: The GitHub Pull Requests extension if you want the three right-click commands. Without it, you can still use the two palette commands.

Settings

All settings live under the prReview.* prefix.

Tool scopes

• read-only (default): readFile, listDir, grep, gitShow. No side effects. In *-no-checkout modes these reads are routed through git so the agent sees the target branch's state even though your workspace is on a different branch.
• read-only-with-linters: above plus runLinter with a fixed allowlist (ruff, mypy, bandit, eslint). Each invocation runs the linter against the workspace; the agent can choose to run any of them.
• shell-with-confirm: above plus runShell. Each shell call prompts you with a modal Approve/Deny dialog before running.

Templates

Bundled in templates/:

• python-reviewer.md — PEP 8, type hints, Pythonic patterns, security (SQL/command injection, eval/exec, weak crypto), framework checks (Django / FastAPI / Flask). Triggered by .py and .pyi (stub) files.
• typescript-reviewer.md — type safety, async correctness, XSS / prototype pollution, idioms. Triggered by .ts / .tsx / .js / .jsx / .mjs / .cjs.
• generic-reviewer.md — language-agnostic fallback.

The template loader picks one (or more) based on extensions of the changed files. If prReview.extraInstructions[lang] is set, the contents of that file are appended after the bundled template. Both layers are prepended to the agent's system prompt.

To customize: either edit the bundled .md (rebuild required) or add an extraInstructions entry pointing at a file in your repo.

How review-without-checkout works

In pr-no-checkout and branch-no-checkout modes, the workspace stays on whatever branch you have open. The agent's file-reading tools detect the active ref in their ToolContext and route through git plumbing:

• readFile → git show <ref>:<path>
• listDir → git ls-tree <ref> <path>
• grep → git grep <pattern> <ref>

This is the safe way to review a PR from the right-click menu without disturbing your working tree, and the model still sees the PR's actual file contents — not yours.

Known limitations

• The GitHub PR extension's tree-node shape isn't public API. PR-number extraction probes pullRequestModel.number, pullRequest.number, item.number, prNumber, number. If none match, an InputBox asks you for the PR number — the right-click flow still works, just with one extra dialog.
• In worktree mode, "open file at line" opens the file from the temp worktree directory rather than the workspace folder — line numbers align with the review, but the editor opens outside the workspace tree so workspace-scoped features (project-wide find, file explorer focus) won't include it.
• branch-checkout on a remote ref like origin/foo may detach HEAD (depending on your git version); the review itself still works. Use a local branch name to avoid this.
• The grep tool searches tracked files via git grep (the workspace must be a git repo). Untracked files are not searched; use readFile for those.
• Agent loops are bounded by prReview.maxAgentIterations. If you see "Agent did not terminate within N iterations," raise it or check the Copilot logs.

Development

npm install
npm run watch        # tsc -watch + esbuild --watch run in parallel
# F5 in VS Code to launch the Extension Development Host (loads ./dist/extension.js)

The shipped extension is a single bundled file (dist/extension.js, esbuild, ~132 KB) — the VSIX contains ~11 files instead of the unbundled ~280. tsc still emits out/ for integration tests; dist/ is what main in package.json points at and what VS Code actually loads.

Scripts:

Project layout:

src/
  extension.ts            # activate() registers commands
  types.ts                # Finding, ReviewDecision, ReviewMode, etc.
  config/settings.ts      # typed wrappers over workspace config
  git/                    # exec, branch, diff, fetch, worktree, refRead
  templates/index.ts      # language detection + template loader
  agent/
    loop.ts               # vscode.lm sendRequest loop (parallel tool execution)
    tools/                # readFile, listDir, grep, gitShow, linters, shell, submitFindings
  github/                 # auth, client (Octokit dynamic import), findPr, submitReview
  commands/
    runReview.ts          # registers all 5 commands; shared review pipeline
    modes.ts              # resolveTarget(): mode → cwd, workspace, refs, cleanup
    prNode.ts             # PR-number extraction from tree node + fallback prompt
  webview/
    panel.ts              # ReviewPanel; postMessage bridge
    types.ts              # ToWebview / FromWebview message types
  test/
    unit/                 # vitest; `vscode` is aliased to the stub in `_stubs/`
    integration/          # @vscode/test-electron suite
    _stubs/vscode.ts      # minimal vscode API stub for unit tests
templates/                # bundled .md system prompts (ships outside src/)
media/                    # webview UI assets (HTML, CSS, JS) — also ships outside src/
esbuild.mjs               # bundler entry; reads --production / --watch flags

How the agent loop spends its iterations

The agent runs at most prReview.maxAgentIterations model round-trips per review (one sendRequest = one iteration, regardless of how many tool calls are in the response). To get the most out of that budget:

• Tool calls emitted in the same response run in parallel via Promise.all. Result order is preserved by callId so the model sees them in the order it asked for, regardless of finish order.
• The model's prose between tool calls is preserved in the assistant turn — mid-loop reasoning stays in history so the next iteration doesn't lose context.
• The system prompt explicitly asks the model to batch independent reads in a single response rather than serialize them across iterations.
• readFile and gitShow results are cached per-review, so re-requesting the same path is a no-op.

License

See LICENSE.