Addressing PR Review Comments

Work through inline review comments on a pull request: read them, decide which are valid, make the changes that are warranted, and reply to each thread explaining what was done.

Not every comment deserves a code change. Some are wrong, some are out of scope, some duplicate others, some are stylistic preferences that conflict with project conventions. Engage with each comment honestly rather than capitulating to all of them.

Pre-flight check

Run these checks before doing anything else. Fail fast — it's better to stop here than to discover a problem halfway through making changes.

1. gh CLI authenticated. Run gh auth status. If it reports the user is not logged in, or the token lacks repo scope, stop and ask the user to authenticate. Don't attempt to proceed with an unauthenticated CLI.
2. Inside a git repo with a remote. Run git rev-parse --is-inside-work-tree and git remote get-url origin (or whichever remote points to the PR's host). If either fails, stop — there's no PR to address.
3. Working tree clean. Run git status --porcelain. If there are uncommitted or staged changes, stop and ask the user how to proceed. Options: stash them (git stash push -m "pre-review-changes"), commit them first, or abort. Do not silently mix the user's in-progress work with review-feedback commits.
4. On the PR's head branch. After identifying the PR (next section), verify the current branch matches the PR's headRefName. If not, ask the user before switching — they may have intentionally checked out a different branch.
5. Branch up to date with remote. Run git fetch origin <head-branch> then compare with git rev-list --left-right --count HEAD...origin/<head-branch>. If the remote is ahead, pull before making changes (the reviewer may have pushed a fixup). If the local branch is ahead, note it — those unpushed commits may already address some comments.
6. Base branch not diverged catastrophically. Run git rev-list --count origin/<base-branch>..HEAD and the reverse. If the base branch is far ahead, warn the user — merge conflicts are likely and should be resolved as a separate commit before review-feedback commits.

If any check fails or surfaces something unexpected, stop and report what was found before continuing.