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:

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 actions: skip to Step 5.

If Yes, checkout and test:

1. Checkout the PR locally:

   • If Platform is github: gh pr checkout <number>
   • If Platform is bitbucket: git fetch origin <branch> && git checkout <branch> (use the branch name from the PR metadata fetched in Step 1)

2. Run the project's test command:

   • Read testing-patterns.md from the code patterns directory (the Code patterns path in ## Arness config) for the test command.
   • If a test command is found: run it via Bash.
   • If no test command is found: inform the user and suggest they run tests manually.

3. Present results:

   • If all tests pass: "All tests pass locally."
   • If tests fail: show the failures, offer to investigate.

4. Open-ended exploration: "Take your time testing locally. Say 'done testing' when ready to continue."

   • This is plain text (not AskUserQuestion — it is conversational).
   • The user can ask questions, run commands, and explore the code.
   • When they say "done testing" or similar, proceed to Step 5.

5. Cleanup after all actions are complete: At the very end of the skill (after Step 6 finishes), return to the original branch:

   git checkout main 2>/dev/null || git checkout master 2>/dev/null || git checkout -

Step 5: Offer Actions

Use AskUserQuestion with multiSelect: true so the user can combine actions. If no options are selected, treat as "do nothing" (take the report as information only).

1. Fix valid issues now — apply suggested fixes for VALID issues directly in the code.
2. Create tracking issues for deferred items — for items that don't need to be fixed in this PR but should be tracked. Tag with arness-backlog label. Ask for priority level (arness-priority-high, arness-priority-medium, arness-priority-low — default low). Use the deferred issue template from ${CLAUDE_PLUGIN_ROOT}/skills/arn-code-review-pr/references/deferred-issue-template.md.
3. Plan and fix via Arness pipeline — for Critical/Moderate VALID items, route through the Arness pipeline (run /arn-code-plan to generate an implementation plan). Only available if ## Arness config exists in CLAUDE.md.

Step 6: Execute Chosen Actions

Fix Inline

For each VALID finding the user approved for fixing:

1. Explain the fix before applying: Present what will be changed:

   Fixing SIM-001 [Critical] in src/auth/login.ts:42
   Current: [brief description of current code]
   Change: [brief description of what will be changed and why]

2. Apply the fix: Make the code change.

3. Verify: Run targeted tests relevant to the changed file to confirm the fix doesn't break anything. If tests fail, attempt to fix (up to 3 attempts). If still failing, revert and inform the user.

4. After all fixes are applied, show a summary of all changes:

   Fixes applied: [N]
   Files modified: [list]
   Tests run: [pass/fail status]

5. Ask before committing and pushing:

   Ask (using AskUserQuestion):

   "Fixes applied and tested. Commit and push these changes?"

   Options:

   1. Yes, commit and push — commit all fixes with a descriptive message and push to the PR branch
   2. Yes, and don't ask again this session — commit, push, and auto-commit for remaining PRs in this session
   3. No, I'll handle it — leave changes uncommitted for the user to review manually

   If Yes, commit and push or Yes, don't ask again:

   • Stage the fixed files: git add <files>
   • Commit: git commit -m "Address PR review: [N] fixes applied"
   • Push: git push
   • If "don't ask again": set a session flag so subsequent fix rounds skip this confirmation

   If No: inform the user that changes are applied locally but not committed. They can review with git diff and commit manually.

Create Issues

For each deferred item, create a tracking issue. On GitHub, use gh issue create with the deferred issue template. On Bitbucket with Jira, use the Atlassian MCP server. See ${CLAUDE_PLUGIN_ROOT}/skills/arn-code-review-pr/references/deferred-issue-template.md for platform-specific commands and templates. Ensure labels exist (create if missing). Report created issue numbers and URLs.

Pipeline Route

Run /arn-code-plan with the VALID findings as context for the plan.

Error Handling

• GitHub not available — inform user, suggest configuring via /arn-reviewing-pr.
• Bitbucket bkt CLI not available or not authenticated — inform user, suggest checking bkt auth status and bkt auth login.
• No PR found for current branch (GitHub) — ask user for a PR number.
• No PR found for current branch (Bitbucket) — ask user for a PR number or URL. Suggest creating one via /arn-code-ship.
• PR is MERGED/CLOSED (GitHub) — warn that comments may be stale, proceed if user confirms.
• PR is MERGED/DECLINED (Bitbucket) — warn that comments may be stale, proceed if user confirms.
• No substantive comments — inform user and exit.
• gh api rate limited — inform user, suggest trying again later.
• bkt command fails — show the error, suggest checking bkt auth status.
• arn-code-architect agent fails — skip architectural assessment, note in report.
• Platform field missing — fall back to legacy GitHub: yes detection. If neither found, treat as none.