From arn-code
This skill should be used when the user says "review PR", "review pull request", "check PR comments", "review PR feedback", "review PR 123", "analyze PR comments", "validate PR review", "address PR feedback", "fix PR issues", "what did the reviewer say", "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).
npx claudepluginhub appsvortex/arness --plugin arn-codeThis skill uses the workspace's default tool permissions.
Searches, retrieves, and installs Agent Skills from prompts.chat registry using MCP tools like search_skills and get_skill. Activates for finding skills, browsing catalogs, or extending Claude.
Searches prompts.chat for AI prompt templates by keyword or category, retrieves by ID with variable handling, and improves prompts via AI. Use for discovering or enhancing prompts.
Compares coding agents like Claude Code and Aider on custom YAML-defined codebase tasks using git worktrees, measuring pass rate, cost, time, and consistency.
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.
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.
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:
gh pr view --json number,title,url,state,headRefName for the current branch.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.
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:
bkt pr view <id> --jsonbkt pr list --state OPEN --limit 5 --json
/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.
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:
Filter out bot comments and CI status messages. If no substantive comments remain, inform the user and exit.
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:
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.
For each substantive review comment:
arn-code-architect agent for assessment.| 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 |
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).
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?"
If No, proceed to actions: skip to Step 5.
If Yes, checkout and test:
Checkout the PR locally:
github: gh pr checkout <number>bitbucket: git fetch origin <branch> && git checkout <branch> (use the branch name from the PR metadata fetched in Step 1)Run the project's test command:
testing-patterns.md from the code patterns directory (the Code patterns path in ## Arness config) for the test command.Present results:
Open-ended exploration: "Take your time testing locally. Say 'done testing' when ready to continue."
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 -
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).
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./arn-code-plan to generate an implementation plan). Only available if ## Arness config exists in CLAUDE.md.For each VALID finding the user approved for fixing:
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]
Apply the fix: Make the code change.
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.
After all fixes are applied, show a summary of all changes:
Fixes applied: [N]
Files modified: [list]
Tests run: [pass/fail status]
Ask before committing and pushing:
Ask (using AskUserQuestion):
"Fixes applied and tested. Commit and push these changes?"
Options:
If Yes, commit and push or Yes, don't ask again:
git add <files>git commit -m "Address PR review: [N] fixes applied"git pushIf No: inform the user that changes are applied locally but not committed. They can review with git diff and commit manually.
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.
Run /arn-code-plan with the VALID findings as context for the plan.
/arn-reviewing-pr.bkt CLI not available or not authenticated — inform user, suggest checking bkt auth status and bkt auth login./arn-code-ship.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.GitHub: yes detection. If neither found, treat as none.