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": "src/services/orders.py", "content": "..."} ], "focus_symbol": "process_order" } } ``` 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": "src/server/main.py", "content": "...file contents..."}, {"path": "src/services/orders.py", "content": "..."} ], "focus_symbol": "process_order", "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.