# Ucx Pr Review > Review UCX pull requests with the project review style, GitHub workflow, and reviewer checklist. Use when asked to review a UCX PR, inspect a GitHub pull request, draft review comments, triage PR scope, or apply REVIEW.md guidance. - Skill: `openucx/ucx-pr-review` (Agent Skill) - Install (CLI): `npx skillmds@latest add openucx/ucx-pr-review` - Raw SKILL.md: https://api.skillmd.com/api/skills/openucx/ucx-pr-review/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Productivity - Author: openucx (https://skillmd.com/u/openucx) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/openucx/ucx-pr-review --- # UCX PR Review ## Overview Use this skill to review UCX pull requests. It layers GitHub operating procedure on top of the repository review checklist in `REVIEW.md`. ## Sources Read these files before making review claims: - `REVIEW.md`; it points to the repository guides and style docs to load for changed paths. ## Code Checkout Use a separate shallow clone as reference for surrounding code and related context from other files in the codebase; do not disturb the user's worktree. ```sh user_name=$(id -un) repo_dir=$(mktemp -d "${TMPDIR%/}/ucx-pr-${user_name}-.XXXXXX") git clone --depth=1 --branch https://github.com/openucx/ucx.git "$repo_dir" git -C "$repo_dir" fetch --depth=1 origin pull//head:pr- git -C "$repo_dir" checkout pr- git -C "$repo_dir" rev-parse HEAD ``` ## GitHub Workflow 1. Identify the base branch, changed files, added/deleted line count, CI state, and author intent from the PR title and description. 2. Treat the GitHub/app/`gh` PR diff as authoritative for changed files and review line anchors. 3. Apply the PR size and scope rules from `REVIEW.md`. 4. Apply the risk order and checklist from `REVIEW.md`. 5. Run the candidate-comment gate below before keeping any finding. 6. Run the review-submission self-check before returning or posting the review. If the `gh` CLI is available and the user permits network access, useful commands are: ```sh gh pr view --json title,body,baseRefName,headRefName,additions,deletions,changedFiles,comments,latestReviews,files,statusCheckRollup gh pr diff gh pr checks ``` ## Prior Discussion Before reviewing the diff and again immediately before submitting, fetch the complete paginated history of inline comments, top-level comments, reviews, and replies; `gh pr view` alone does not provide it: ```sh gh api --paginate repos///pulls//comments gh api --paginate repos///issues//comments gh api --paginate repos///pulls//reviews ``` If any fetch fails, do not submit findings; report that duplicate detection could not be completed. Build or update one ledger, grouping inline replies by `in_reply_to_id`. Compare every candidate comment with the full conversation by meaning, not exact wording or line. Discard it if the same concern, question, requested change, explanation, or intent is already present, or if a reply already answers it, including when the code moved in a newer revision. If the same issue remains unresolved, add a `+1` reaction instead of opening a new thread. For inline PR review comments, use: ```sh gh api -X POST repos///pulls/comments//reactions \ -H "Accept: application/vnd.github+json" \ -f content="+1" ``` For top-level PR conversation comments, use `repos///issues/comments//reactions` instead. If new evidence changes an existing concern, reply in its thread. If the author gave a good explanation, move on unless the current code or CI contradicts it. ## Candidate Comment Gate Keep a finding only after verifying all of these: - The issue is still present in the latest diff. - The comment is anchored to a changed line, or clearly belongs as PR-level feedback. - The impact is concrete. - The severity matches `REVIEW.md`. ## Review Submission - Submit reviews explicitly with `gh`, not the GitHub app connector. - Use the tone, severity, and length rules from `REVIEW.md`. - Accumulate all inline comments and submit them in one review submission. Do not submit one GitHub review per comment. - Leave the review body empty unless there is a real PR-level concern. - Do not generate boilerplate review summaries, finding counts, severity counts, or `Code Review` headings. - Remove comments that are only interesting observations and any finding whose impact is unclear. - Scrub comments for `REVIEW.md` style violations such as severity headings, emoji labels, `[P*]` labels, and uppercase severity labels. - Check every inline comment for suggestion eligibility. If the requested fix is an obvious, small, deterministic replacement of changed lines, use a GitHub suggestion block instead of prose-only feedback; add at most one short justification sentence after it. - Downgrade uncertain blockers to questions or no-prefix comments. - Use `COMMENT` mode when all comments are minor or explicitly non-blocking. - Use `REQUEST_CHANGES` mode when there are blocker or other must-fix findings. - Use `APPROVE` mode when there are no comments. - For review-body-only submissions, use `gh pr review --repo /` with exactly one of `--comment`, `--request-changes`, or `--approve`; pass non-empty review text with `--body-file ` to avoid shell quoting issues. - For inline comments, create one review through `gh api` and the GitHub `POST /repos/{owner}/{repo}/pulls/{pull_number}/reviews` endpoint. Put the event (`COMMENT`, `REQUEST_CHANGES`, or `APPROVE`), optional body, and all inline comments in a temporary JSON file and submit it with: ```sh gh api -X POST repos///pulls//reviews --input ``` ## Output When returning a review in chat, use one of these formats: - Findings: list each issue with severity, `file:line`, problem, and impact. - Draft GitHub comments: provide the exact proposed comment text for each changed line. - No findings: say so and note residual test or hardware coverage gaps.