shreyT19 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-revieworadvanced-review(skip understanding step) - Understanding a random subsystem, not a PR — use
teach(which chainshow+whyon any code)
Inputs
One of:
- PR number:
<n>(assumesoriginremote) - PR URL:
https://github.com/<org>/<repo>/pull/<n> - Local branch:
<branch>(compare againstmainunless told otherwise)
If none supplied, ask.
Process
1. Fetch PR metadata + diff
Use gh CLI:
gh pr view <n-or-url> --json title,body,author,commits,files,baseRefName,headRefName,url— metadatagh pr diff <n-or-url>— full diffgh pr view <n-or-url> --json commits -q '.commits[].messageHeadline'— commit list
If gh fails or PR is local-only:
git diff <base>...<branch>git log <base>..<branch> --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.
## <PR title> #<n> by @<author>
<base> ← <head> | <N> 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**
- <verb-first, 3 to 6 bullets, one line each — grouped by area if many files>
**Why it's needed**
- Author's stated reason (from PR body / commits): <quote or paraphrase>
- Historical context (if `why` was invoked): <brief>
**Downstream impact** (from `blast-radius`)
- <who / what is affected>
- <what likely breaks if merged as-is>
- <any consumer NOT updated in this diff>
**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-loadconventions - 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