# Pr Brief > Reviewer-oriented brief of an incoming PR. Fetches PR metadata + diff, invokes interrogate (what the code does) and blast-radius (downstream impact), optionally why (historical rationale for legacy touched code), then composes a plain-English brief with TL;DR, what-changes, why-needed, downstream impact, and watch-points for review. Use BEFORE reviewing when a teammate sends a PR and you need to understand it. Handoff to `quick-review` / `medium-review` / `advanced-review` after for judgment. - Skill: `shreyt19/pr-brief` (Agent Skill) - Install (CLI): `npx skillmds@latest add shreyt19/pr-brief` - Raw SKILL.md: https://api.skillmd.com/api/skills/shreyt19/pr-brief/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: shreyT19 (https://skillmd.com/u/shreyt19) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/shreyt19/pr-brief --- # PR brief Orchestrator — mixes `interrogate` + `blast-radius` (+ optional `why`) with a `gh` fetch to give the *reviewer* (you) a fast mental model of an incoming PR before any judgment pass. ## When to use - Teammate opens a PR and asks you to review - You are pinged on a PR in a repo / area you don't own - You need to write a good review comment but first need to understand *what* + *why* + *what breaks* ## When NOT to use - Your own WIP diff — use `quick-review` - Just judging quality — use `medium-review` or `advanced-review` (skip understanding step) - Understanding a random subsystem, not a PR — use `teach` (which chains `how` + `why` on any code) ## Inputs One of: - PR number: `` (assumes `origin` remote) - PR URL: `https://github.com///pull/` - Local branch: `` (compare against `main` unless told otherwise) If none supplied, ask. ## Process ### 1. Fetch PR metadata + diff Use `gh` CLI: - `gh pr view --json title,body,author,commits,files,baseRefName,headRefName,url` — metadata - `gh pr diff ` — full diff - `gh pr view --json commits -q '.commits[].messageHeadline'` — commit list If gh fails or PR is local-only: - `git diff ...` - `git log .. --oneline` - Skip anything requiring API access, note gaps. Note down: files changed, LOC added/removed, linked issues (parse `#123`, `Closes #45`, `Fixes ABC-1234` from body + commits). ### 2. Invoke `interrogate` Delegate to `interrogate` skill. Brief: "For files [list] in this PR, explain what each does, its main callers, and any subtle behavior a reviewer needs to know before judging changes in the diff [attach diff]. Focus on changed regions." Capture output. Do not re-derive. ### 3. Invoke `blast-radius` Delegate to `blast-radius` skill. Brief: "Given this diff [attach] touching files [list], what else in the repo depends on the changed symbols / interfaces / files? What could break downstream if this ships? Include implicit consumers (fixtures, generated code, docs)." Capture output. ### 4. Optional: invoke `why` (only if worth it) Trigger `why` ONLY when: - Diff modifies existing (non-trivial) code AND - PR description does not already explain motivation clearly Skip when: - Pure additions (new files, new features) — nothing historical to explain - PR body already gives full context - User asked for a fast brief Brief to `why`: "Why does the code at [files/regions] exist in its current shape? Focus on the touched regions only, not the surrounding subsystem. Under 150 words." ### 5. Compose the brief Fixed structure. Drop empty sections. ``` ## # by @ ← | files, +A / -R lines | [linked issues] **TL;DR** — one paragraph, plain English. What this PR does and the one reason it exists. **What it changes** - **Why it's needed** - Author's stated reason (from PR body / commits): - Historical context (if `why` was invoked): **Downstream impact** (from `blast-radius`) - - - **Watch when reviewing** - 2 to 4 concrete focus points a reviewer should scrutinize - Rank most-important first **Gaps in this brief** - (Only include if something couldn't be fetched or was skipped: private issue, external API, huge generated file) ``` ### 6. Suggest a next step End with one line: > Next: run `quick-review` (fast) / `medium-review` (proper) / `advanced-review` (deep, has spec) for judgment. Pick the tier that matches PR size and formality. Do not run it — let the user choose. ## Output style - Under one screen for typical PRs (< 15 files) - No praise. No "overall looks fine" filler. - Apply `principle-minimize-reader-load` conventions - Apply `unslop` — no AI voice ## Notes - Never post the brief to the PR unless the user explicitly asks - Never include AI/Claude attribution - If PR is huge (> 500 lines diff), warn and group summary by file cluster instead of listing every file