PR Review

XPU PR Review Skill

Review torch-xpu-ops pull requests focusing on what CI cannot check: correctness against CPU/CUDA semantics, XPU-specific risks (synchronization, indexing, precision), test adequacy, and backward compatibility.

Detailed reference:

• torch-xpu-ops-review-notes.md
• review-checklist.md
• bc-guidelines.md
• pr-submission-guidelines.md — for PR authors (process & etiquette)

Usage Modes

No Argument

If the user invokes /pr-review with no arguments, do not perform a review. Instead, ask:

What would you like me to review?

• A PR number or URL (e.g., /pr-review 12345)
• A local branch (e.g., /pr-review branch)

Local CLI Mode

The user provides a PR number or URL:

/pr-review 12345
/pr-review https://github.com/intel/torch-xpu-ops/pull/12345

For a detailed review with line-by-line specific comments:

/pr-review 12345 detailed

Use gh CLI to fetch PR data:

# Get PR details
gh pr view <PR_NUMBER> --json title,body,author,baseRefName,headRefName,files,additions,deletions,commits

# Get the diff
gh pr diff <PR_NUMBER>

# Get PR comments
gh pr view <PR_NUMBER> --json comments,reviews

Local Branch Mode

Review changes in the current branch that are not in main:

/pr-review branch
/pr-review branch detailed

Use git commands to get branch changes:

# Get current branch name
git branch --show-current

# Get list of changed files compared to main
git diff --name-only main...HEAD

# Get full diff compared to main
git diff main...HEAD

# Get commit log for the branch
git log main..HEAD --oneline

# Get diff stats (files changed, insertions, deletions)
git diff --stat main...HEAD

For local branch reviews:

• The "Summary" should describe what the branch changes accomplish based on commit messages and diff
• Use the current branch name in the review header instead of a PR number
• All other review criteria apply the same as PR reviews

GitHub Actions Mode

When invoked via @copilot /pr-review or @claude /pr-review on a GitHub PR, detect this mode by the presence of <formatted_context>, <pr_or_issue_body>, and <comments> tags in the prompt.

The prompt already contains:

• PR metadata (title, author, branch names, additions/deletions, file count)
• PR body/description
• All comments and review comments (with file/line references)
• List of changed files with paths and change types

Use git commands to get the diff and commit history. The base branch name is in the prompt context (look for PR Branch: <head> -> <base> or the baseBranch field).

# Get the full diff against the base branch
git diff origin/<baseBranch>...HEAD

# Get diff stats
git diff --stat origin/<baseBranch>...HEAD

# Get commit history for this PR
git log origin/<baseBranch>..HEAD --oneline

# If the base branch ref is not available, fetch it first
git fetch origin <baseBranch> --depth=1

Do NOT use gh CLI commands in this mode -- only git commands are available. All PR metadata, comments, and reviews are already in the prompt context; only the diff and commit log need to be fetched via git.

Review Philosophy

1. Only report problems — The review output must contain only issues, concerns, and actionable suggestions. Do NOT mention things that are done correctly, do NOT praise good decisions, do NOT explain why something is fine. If a section has no problems, omit it entirely. The reader's time is precious — every sentence must point to something that needs fixing or further discussion.
2. Investigate, don't guess — When uncertain whether a checklist item applies, spawn a sub-agent to read the relevant code. A reviewer who guesses wrong provides negative value.
3. Review the design, not just the implementation — A PR can have perfectly correct implementation of a bad design. Question side-channel communication, on/off private flags, and demand concrete interface documentation for new contracts between components.
4. Focus on what CI cannot check — Don't comment on formatting, linting, type errors, or CI failures. Focus on design quality, interface correctness, thread safety, BC implications, test adequacy, and pattern adherence.
5. Everything is a must-fix — There are no "nits." If it's worth mentioning, it's worth fixing. Every inconsistency degrades the codebase over time.
6. Be specific and actionable — Reference file paths and line numbers. Name the function/class/file the author should use.
7. Match the immediate context — Read how similar features are already implemented in the same file. Pattern mismatches within a file are always wrong.
8. Assume competence — The author knows PyTorch; explain only non-obvious context.
9. No repetition — Each observation appears in exactly one section of the review output.
10. Verify CPU/CUDA parity from source — Do not infer behavior from memory. Inspect the actual upstream implementation from pytorch/pytorch.

Using sub-agents

The review checklist is large. Spawn sub-agents to investigate whether checklist items apply: read surrounding code, check upstream PyTorch implementation for parity, or verify tests exist. Spawn them in parallel for independent areas.

Review Workflow

Step 1: Understand Context

Before reviewing, build understanding of what the PR touches and why:

1. Identify the purpose of the change from title/description/issue
2. Group changes by type (new code, tests, config, docs)
3. Note the scope of changes (files affected, lines changed)
4. Spawn sub-agents to read the unchanged code surrounding each significantly changed file to understand existing patterns and infrastructure

Step 2: Verify Upstream Semantics

For every changed kernel or operator file, fetch and read the corresponding upstream PyTorch implementation BEFORE evaluating correctness:

• src/ATen/native/xpu/<Op>.cpp → read aten/src/ATen/native/<Op>.cpp
• src/ATen/native/xpu/sycl/<Op>Kernels.cpp → read aten/src/ATen/native/cuda/<Op>.cu
• Shared math utilities (e.g., MathExtensions.h) → read aten/src/ATen/native/Math.h

Use gh api or spawn a sub-agent to fetch the upstream file content. Do NOT proceed to the deep review until upstream code has been read. Quote or summarize relevant upstream patterns in your working notes before continuing.

Step 3: Deep Review

Go through every changed line in the diff and evaluate against the review checklist in review-checklist.md.

If the diff adds or modifies any agent instruction files (SKILL.md, AGENTS.md, claude.md, copilot-instructions.md, or files under .claude/ / .github/), load the skill-writer skill and evaluate those changes against its guidelines. Do NOT skip this — treat it as a blocking gate for those files.

Pay special attention to XPU-specific risks:

• Synchronization: hidden host sync, unnecessary synchronize, stream misuse
• Indexing: 32-bit vs 64-bit indexing, large tensor overflow risk
• Layout: contiguous vs non-contiguous, channels_last handling
• Precision: FP32 / BF16 / FP16 behavior, accumulation dtype, AMP impact
• Kernel efficiency: branch divergence, work-group choice, unnecessary copies
• Fallback/dispatch: wrong registration, silent fallback, inconsistent path coverage

Step 4: Check Backward Compatibility

Evaluate BC implications per bc-guidelines.md. For non-trivial BC questions, spawn a sub-agent to search for existing callers of the modified API.

Step 5: Formulate Review

Structure your review with actionable feedback organized by category. Every finding should be traceable to a specific line in the diff.

Step 6: Fact-Check

After drafting the review, spawn a sub-agent per reported issue (in parallel) to independently verify the claim by re-reading the relevant code. Drop invalid issues, reword uncertain ones with a note about confidence level.