review-pr-against-issue

name	review-pr-against-issue
description	Review one or more PRs against the GitHub issue(s) they claim to fix, including fetching PR branches directly when `gh` can't reach github.com (e.g. gh is authenticated to an enterprise host instead). Use whenever asked "does this PR fix issue

Review a PR against the issue it claims to fix

1. Get the issue text

Try gh issue view <N> --repo intuit/infigraph --json title,body,labels,state. If gh auth status shows you're authenticated to a different host (e.g. github.intuit.com instead of github.com), gh calls will 404/401 even though the repo is public. Either:

• GH_HOST=github.com gh issue view <N> --repo intuit/infigraph ... (works if a github.com token exists), or
• WebFetch the issue URL directly (https://github.com/intuit/infigraph/issues/<N>) — works for public repos with no auth needed.

Extract the issue's root cause and, if present, its numbered list of distinct sub-defects/suggestions — don't treat the issue as one monolithic bug if it enumerates several. A PR can close the headline symptom while leaving half the listed defects untouched.

2. Get the PR

gh pr view will hit the same host problem. WebFetch the PR URL for description/stated-issue-link, then pull the actual diff locally (WebFetch can't reliably render diffs):

git fetch https://github.com/intuit/infigraph.git refs/pull/<N>/head:pr-<N>
git diff main pr-<N> -- . ':!*.lock'

This works read-only with no auth, for any public repo, regardless of what host gh is configured for. Repeat per PR into separate pr-<N> local branches — cheap, and lets you diff them against each other too.

3. Match diff to root cause, not just to the title

For each sub-defect in the issue:

• Grep the current (pre-fix, main) code for the exact broken behavior described (e.g. a hardcoded flag, a missing guard, a skipped check) to confirm the issue's own description is still accurate before crediting a PR with fixing it.
• Check whether the PR's diff actually touches the file/line the issue points to.
• If the issue names specific "suggested fixes" (plural), check each independently — PRs frequently fix the primary suggestion and skip the rest (logging/diagnostics ones especially tend to get dropped).

Don't assume a PR closes an issue just because its description says "Fixes #N" — verify against the diff.

4. When multiple PRs are being merged together

• Check same-author + same-base-commit doesn't imply no-conflict — verify explicitly:

  git checkout -b merge-test-all main
  git merge --no-edit pr-<N>   # repeat per PR
  

  Clean merges only guarantee no textual conflict, not that combined behavior is correct — still run build+test on the merged tree.
• cargo build --workspace then cargo test --workspace --no-fail-fast on the merged branch (this repo's CI equivalent — see root CLAUDE.md). Run test in background (run_in_background: true) if it's a large workspace; check .output file or wait for the completion notification rather than polling.
• Delete the scratch branch/refs when done, or leave them if the user wants to keep testing — don't push them anywhere.

5. Report format

Per PR: root-cause match (yes/no/partial), which specific sub-defects it closes vs. leaves open, any gaps in the fix itself. Then an overall verdict — will merging all of them actually close the issue(s), or does it need to stay open / get rescoped to a checklist matching only what's fixed — with a confidence and recommendation per the repo's working convention.