walkthrough-pr

Guide the user through a PR's changes one file per step. Never dump the whole diff. Each step covers a single file, in 2–3 lines, then stop and wait for the user to confirm they reviewed it before moving on.

Procedure

1. Resolve the diff. Determine the change set:
   • If the user named a PR number, fetch it: gh pr diff <number> --name-only for the file list, gh pr diff <number> for content.
   • Otherwise use the local branch vs base: git diff --name-only <base>...HEAD. Detect the base instead of guessing: git symbolic-ref refs/remotes/origin/HEAD or gh repo view --json defaultBranchRef -q .defaultBranchRef.name; ask the user only if both fail.
   • Detect renames/moves (git diff -M --name-status) so a moved file isn't walked as a full delete + add. A pure move gets one cheap step: moved X → Y, logic unchanged, plus a line on any edits made in transit.
   • Exclude test files from the walkthrough list. Drop paths that are clearly tests (e.g. *.test.*, *.spec.*, __tests__/, test/, tests/, *_test.go, *_test.py, snapshots/fixtures used only by tests). Mention in the opening line how many test files were skipped if any. If the user asks to include tests, walk them separately.
   • Exclude generated and vendored files. Lockfiles (package-lock.json, yarn.lock, pnpm-lock.yaml, Cargo.lock, *.lock), build output (dist/, build/), *.generated.*, *.min.*, vendored deps, snapshots. Never walk a user through a lockfile diff — note it in one line ("lockfile updated for the new dep") and move on.
   • Huge PRs (~30+ production files): don't walk every file. List the independent sub-flows with file counts and ask which to walk (default: riskiest / most central first). Within a chosen flow, proceed file-by-file as normal.