code-review skill silently reviews the local diff instead of failing when given an unresolvable PR number
Description
The built-in code-review skill accepts a PR number, branch name, or file path as its argument, per its own listed description ("Review the current diff, or a PR number/branch/path target..."). But its diff-gathering step only ever runs git diff @{upstream}...HEAD / main...HEAD / HEAD~1 against whatever is currently checked out locally - there's no gh pr checkout/gh pr diff resolution step for a PR-number argument.
Given a bare PR number that doesn't correspond to any local ref (e.g. /code-review 155), the skill silently falls back to diffing the current local branch and reports the result as if it had reviewed the requested PR - no error, no warning that the wrong thing was reviewed.
Reproduction
- Have an unrelated local branch checked out (not the PR's branch).
- Run
/code-review <PR number>for a PR that isn't checked out locally. - The skill returns a full review, but of the local branch's diff, not the PR's actual diff.
Impact
This is a silent failure mode that can produce a confidently-wrong review - I hit this reviewing PR #155 on a large monorepo: the skill reviewed a small, unrelated branch (feature/steve/destroy-dev-appconfig-fix) that happened to be checked out, and reported all 10 findings as if they were PR #155's. It took manually diffing the PR branch to catch the mismatch.
Expected behavior
Given a PR-number-shaped argument, the skill should resolve it via gh pr view/gh pr checkout/gh pr diff first, and fail loudly (clear error, no review produced) if that resolution doesn't succeed - never silently substitute the local checkout's diff for the requested PR's diff.
Workaround
I built a project-level wrapper skill that resolves the PR via gh pr view first and fails loudly before handing off to code-review with a proper branch-diff target. Happy to share the implementation if useful as a reference.