/arn-code-review-pr

name: arn-code-review-pr
description: >-
  This skill should be used when the user says "arn-code-review-pr",
  "review PR feedback", "analyze PR comments", "validate PR review",
  "review Bitbucket PR",
  or wants to validate GitHub or Bitbucket
  PR review comments, categorize findings, and optionally connect back into
  the Arness pipeline for fixes. Do NOT use this for creating PRs (use
  arn-code-ship) or reviewing implementation quality (use arn-code-review-implementation).
version: 1.1.0
argument-hint: "[pr-number-or-url]"

Arness Review PR

Reviews PR comments from GitHub or Bitbucket, validates each finding against the actual code, categorizes them by severity, and optionally connects back into the Arness pipeline for fixes or creates tracking issues.

---

Step 1: Find the PR

Read the **Platform** field from `## Arness` config in CLAUDE.md (values: `github`, `bitbucket`, or `none`). If the `Platform` field is not present, fall back to legacy detection: check for `GitHub: yes` and treat as `github`; otherwise treat as `none`.

If Platform is `none`, inform the user: "No platform configured for PR review. Run `/arn-reviewing-pr` to get started." and exit.

If Platform is github

Run a runtime check if needed:

git rev-parse --is-inside-work-tree
# Check for a GitHub remote
git remote -v | grep github.com
# Verify gh CLI is authenticated
gh auth status

If GitHub is not available, inform the user and exit. Suggest configuring via `/arn-reviewing-pr`.

Try to detect the PR automatically:

1. If the user provided a PR number (e.g., "review PR 42"), use that directly. 2. Otherwise, run `gh pr view --json number,title,url,state,headRefName` for the current branch. 3. If no PR is found, ask the user for a PR number or URL.

Display the PR title, number, and URL for confirmation.

Warn if the PR is **MERGED** or **CLOSED** — comments may be stale. Ask the user whether to proceed.

If Platform is bitbucket

Run a runtime check: `bkt auth status`. If `bkt` is not available or not authenticated, inform the user and exit. Suggest checking `bkt auth status`.

Try to detect the PR automatically:

1. If the user provided a PR number or URL, use that directly: `bkt pr view <id> --json` 2. Otherwise, list open PRs: `bkt pr list --state OPEN --limit 5 --json`

• Match the current branch name to find the PR for this branch.

3. If no PR is found, ask the user for a PR number or URL. Suggest creating one via `/arn-code-ship`.

Display the PR title, number, and URL for confirmation.

Warn if the PR is **MERGED** or **DECLINED** — comments may be stale. Ask the user whether to proceed.

---

Step 2: Fetch Comments

If Platform is github

Collect all feedback using the `gh` CLI:

Resolve `{owner}/{repo}` from the current repository: `gh repo view --json nameWithOwner -q .nameWithOwner`.

# Inline code review comments
gh api repos/{owner}/{repo}/pulls/{number}/comments --paginate

# Top-level reviews (approve/request-changes/comment with body)
gh api repos/{owner}/{repo}/pulls/{number}/reviews --paginate

# General conversation comments
gh pr view {number} --comments --json comments

Parse and organize by type:

• **Review comments** — inline, attached to a specific file and line
• **Review verdicts** — approve, request changes, or comment (with body text)
• **General comments** — conversation thread

Filter out bot comments and CI status messages. If no substantive comments remain, inform the user and exit.

If Platform is bitbucket

Collect all feedback using the `bkt` CLI:

# Fetch all PR comments (inline and general)
bkt pr comments <id> --json

# Fetch PR activity (approvals, changes-requested, etc.)
bkt pr activity <id> --json

Parse and organize by type:

• **Review comments** — inline comments that have file path and line number context
• **General comments** — comments without inline context (top-level conversation)
• **Review verdicts** — approval or changes-requested activity entries

Filter out bot and CI messages. If no substantive comments remain, inform the user and exit.

**Note:** Bitbucket inline comments may have less context than GitHub (e.g., no multi-line range, different diff hunk format). When validating comments in Step 3, use the file path and line number to locate the code, but be aware that the surrounding context may be more limited.

---

Step 3: Validate Each Comment

For each substantive review comment:

1. **Read the referenced file and line** — understand the actual code in its current state. 2. **Understand the reviewer's concern** — what issue are they raising? 3. **Check for subsequent fixes** — was this already addressed in a later commit? 4. **For architectural concerns**, invoke the `arn-code-architect` agent for assessment. 5. **Categorize the comment**:

| Category | Meaning | Severity | |----------|---------|----------| | **VALID** | Reviewer is correct — real issue that should be fixed | Critical or Moderate | | **VALID (MINOR)** | Correct but low impact — style, naming, or preference | Low | | **FALSE POSITIVE** | Concern doesn't apply — explain why | None | | **ALREADY FIXED** | Issue addressed in a subsequent commit | None | | **DISCUSSION** | Not an issue — question or design discussion point | None |

---

Step 4: Report

Present findings using the format from `${CLAUDE_PLUGIN_ROOT}/skills/arn-code-review-pr/references/pr-report-format.md`.

Summary counts plus per-comment details with category, severity, assessment, and suggested fix (for VALID items).

---

Step 4.5: Local Testing Offer (Optional)

If Platform is `none`, skip this step entirely (no remote PR to checkout).

After the report is presented, before offering actions:

Ask (using `AskUserQuestion`):

**"Would you like to test this PR locally before deciding on actions?"**

1. **Yes, checkout and test** — Checkout the PR branch and run tests 2. **No, proceed to actions** — Skip local testing

If **No, proceed to act