# Review Pr Diff

> Compresses a git diff before review so noise (lockfile bumps, generated files, whitespace churn) doesn't crowd out the actual logic changes. Use this skill whenever the user asks you to review a pull request, explain a diff, summarize changes, or comment on recent commits. Trigger phrases include "review this PR", "what changed", "explain this diff", "summarize the changes", "look at my diff", "check this branch against main". Uses gotcontext's code-aware compression at fidelity=detailed — detailed because a character dropped in a security fix matters more than a character dropped in prose.

- Skill: `oimiragieo/review-pr-diff` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add oimiragieo/review-pr-diff`
- Raw SKILL.md: https://api.skillmd.com/api/skills/oimiragieo/review-pr-diff/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security
- Author: oimiragieo (https://skillmd.com/u/oimiragieo)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/oimiragieo/review-pr-diff

---


# review-pr-diff

## When this skill is the preferred path

Raw `git diff` output is dominated by bytes the reviewer doesn't care
about: lockfile hash bumps, formatter churn, generated files, vendored
updates. Those hunks drown out the actual logic changes. Compressing
the diff first lets you spend your reasoning budget on what matters.

## How to use it

1. Orient first — call `git diff --stat <base>..HEAD` to see
   file-level scope without loading content. Ask the user for the
   base branch if ambiguous (usually `main` or `master`).
2. Fetch the full diff — `git diff <base>..HEAD`.
3. Strip known noise before compression. Excluded paths:
   - Lockfiles: `package-lock.json`, `yarn.lock`, `pnpm-lock.yaml`,
     `Cargo.lock`, `poetry.lock`, `Gemfile.lock`, `composer.lock`
   - Generated: `*.generated.ts`, `*.pb.go`, `*.min.js`, `*.min.css`
   - Vendored: `vendor/**`, `node_modules/**`, `dist/**`, `build/**`
   - Binary / non-text hunks
4. Call gotcontext's `compress_codebase` MCP tool with the remaining
   file set at `fidelity=detailed`. For a diff spanning ≤20 files on a
   well-understood codebase, `gc_blast_radius` gives you a tighter
   ranked context — pass the changed files + the PR's focus symbol
   (e.g. the primary function name or class) and it returns only the
   touched code plus what transitively calls into it (Pro+ only).

   For a lighter "who calls this changed function?" question without
   the full transitive graph, prefer `gc_callers` (Pro+ only).
   It returns call sites + likely impacted test files for a symbol,
   at lower cost than a full blast-radius run:

   ```json
   {
     "name": "gc_callers",
     "arguments": {
       "files": [
         {"path": "api/app/services/compression.py", "content": "..."}
       ],
       "focus_symbol": "compress"
     }
   }
   ```

   Use the returned impacted_tests list to target your test review —
   if the PR's diff doesn't cover those test files, flag as a risk.

   The required input schema for `gc_blast_radius` is:

   ```json
   {
     "name": "gc_blast_radius",
     "arguments": {
       "files": [
         {"path": "api/app/main.py", "content": "...file contents..."},
         {"path": "api/app/services/compression.py", "content": "..."}
       ],
       "focus_symbol": "compress",
       "top_k": 50
     }
   }
   ```

   `files` must be an array of `{path, content}` objects — not an array
   of path strings, and not a "changed_files" key. Both path and content
   are required for every entry.
5. Present the review in this structure:
   - **Summary** — 2-3 bullets on what the PR does
   - **Logic changes** — grouped by file/area, with line refs
   - **Risk flags** — auth, crypto, migrations, webhooks, cron,
     billing, RBAC, SQL string-building, env var handling
   - **Skipped** — the list of noise files excluded, so the reviewer
     knows they weren't forgotten

## When the raw read is actually fine

- Trivially small diffs (<50 lines). Read them directly.
- You're being asked to WRITE the patch — this skill reviews, not
  authors.

## Why this matters

The skipped-files list is critical. If a reviewer misses a malicious
`package-lock.json` change because you silently excluded it, that's
worse than not using the skill at all. Always surface what was dropped.

See `references/risk-taxonomy.md` for the full list of risk flags to
watch for.