address-review-pr

Name

openshift-developer:address-review-pr

Synopsis

/openshift-developer:address-review-pr [PR number] [--preview]

Description

Automates addressing PR review comments by fetching all comments from a pull request, categorizing them by priority (blocking, change requests, questions, suggestions), and systematically addressing each one. Intelligently filters out outdated comments, bot-generated content, and oversized responses to optimize context usage. Handles code changes, posts replies to reviewers, and maintains a clean git history by amending relevant commits rather than creating unnecessary new ones.

Implementation

Step 0: Checkout the PR Branch

1. Determine PR number: Use $1 if provided, otherwise gh pr list --head <current-branch>
2. Checkout: Use gh pr checkout <PR_NUMBER> if not already on the branch, then git pull
3. Verify clean working tree: Run git status. If uncommitted changes exist, ask user how to proceed

Step 1: Fetch PR Context

1. Fetch PR metadata with selective filtering:

   a. First pass - Get metadata only (IDs, authors, lengths, URLs):

   # Get issue comments (general PR comments - main conversation)
   gh pr view <PR_NUMBER> --json comments --jq '.comments | map({
     id,
     author: .author.login,
     length: (.body | length),
     url,
     createdAt,
     type: "issue_comment"
   })'
   
   # Get reviews (need REST API for numeric IDs)
   # IMPORTANT: Use --paginate to fetch ALL pages (default page size is 30;
   # PRs with many bot/CI reviews easily exceed this, silently dropping recent human reviews)
   gh api repos/{owner}/{repo}/pulls/<PR_NUMBER>/reviews --paginate --jq 'map({
     id,
     author: .user.login,
     length: (.body | length),
     state,
     submitted_at,
     type: "review"
   })'
   
   # Get review comments (inline code comments)
   # IMPORTANT: Use --paginate — same pagination issue as reviews above
   gh api repos/{owner}/{repo}/pulls/<PR_NUMBER>/comments --paginate --jq 'map({
     id,
     author: .user.login,
     length: (.body | length),
     path,
     line,
     original_line,
     created_at,
     type: "review_comment"
   })'
   

   b. Apply filtering logic (DO NOT fetch full body yet):

   • Filter out: line == null AND original_line == null (truly orphaned review comments). Keep comments where line == null but original_line != null — these are valid comments on a stale diff hunk that still need attention.
   • Filter out: length > 5000
   • Filter out: CI/automation bots author in ["openshift-ci-robot", "openshift-ci"] (keep coderabbitai for code review insights)
   • Keep track of filtered items and stats for reporting

   c. Second pass - Fetch ONLY essential fields for kept items:

   # For issue comments:
   gh api repos/{owner}/{repo}/issues/comments/<comment_id> --jq '{id, body, user: .user.login, created_at, url}'
   
   # For reviews:
   gh api repos/{owner}/{repo}/pulls/<PR_NUMBER>/reviews/<review_id> --jq '{id, body, user: .user.login, state, submitted_at}'
   
   # For review comments:
   gh api repos/{owner}/{repo}/pulls/comments/<comment_id> --jq '{id, body, user: .user.login, path, line, original_line, position, diff_hunk, created_at}'
   

   d. Log filtering results:

   Fetched N/M comments (filtered out K large/bot comments saving ~X chars)
   

2. Fetch commit messages: gh pr view <PR_NUMBER> --json commits -q '.commits[] | "\(.messageHeadline)\n\n\(.messageBody)"'

3. Store ONLY the kept (filtered) comments for analysis

Step 2: Categorize and Prioritize Comments

1. Additional filtering (for remaining fetched comments):

   • Already resolved comments
   • Pure acknowledgments ("LGTM", "Thanks!", etc.)

2. Categorize:

   • ACTION_INSTRUCTION: Repo-level operations — rebase, verify, squash, update branch, run tests.
   • BLOCKING: Critical changes (security, bugs, breaking issues)
   • CHANGE_REQUEST: Code improvements or refactoring
   • QUESTION: Requests for clarification
   • SUGGESTION: Optional improvements (nits, non-critical)

3. Group by context: Group by file, then by proximity (within 10 lines)

4. Prioritize: ACTION_INSTRUCTION > BLOCKING > CHANGE_REQUEST > QUESTION > SUGGESTION

5. Present summary: Show counts by category and file groupings, ask user to confirm

Step 3: Address Comments

Interactive Preview (--preview)

When --preview is passed, preview each comment before acting:

1. Show the reviewer's comment
2. Show your proposed action: code change diff, explanation, or decline reasoning
3. Show the draft reply you plan to post
4. Wait for user approval before proceeding

Action Instructions

Process ACTION_INSTRUCTION items first, before any code changes:

1. Rebase: Determine the base remote and branch first:

   BASE_BRANCH=$(gh pr view <PR_NUMBER> --json baseRefName -q '.baseRefName')
   BASE_REMOTE=$(git remote | grep -m1 '^upstream$')
   if [ -z "$BASE_REMOTE" ]; then
     BASE_REMOTE=$(git remote | grep -m1 '^origin$')
   fi
   BASE_REMOTE=${BASE_REMOTE:-origin}
   git fetch "$BASE_REMOTE" && git rebase "$BASE_REMOTE/$BASE_BRANCH"
   

2. Verify/Test: Run the repo's verification commands. If the reviewer asks to "make sure X passes", run X and fix failures before continuing.
3. Squash/restructure commits: Follow the reviewer's instructions on commit organization.

Grouped Comments

When multiple comments relate to the same concern/fix:

• Make the code change once
• Track replies for EACH comment individually (posted in Step 4)

Code Change Requests

a. Validate: Analyze if the change is valid. Don't be afraid to reject it if it doesn't make sense.

b. If valid:

• Implement changes and commit locally (do NOT push yet — batched in Step 4)
• Default to amending the relevant commit. New commit only for substantial new features beyond PR scope.
• Follow Conventional Commits format

c. If declining: Prepare technical explanation (3-5 sentences) with file:line references

d. If unsure: Ask user for clarification

Clarification Requests

• Prepare clear, detailed answer (2-4 sentences) with file:line references

Step 3.5: Pre-Push Verification

1. Detect verification commands (first match):

   • Makefile with verify target -> make verify
   • Makefile with lint target -> make lint
   • go.mod exists -> go build ./... and go vet ./...
   • package.json with lint script -> npm run lint

2. Run verification (15-minute timeout). Maximum 3 retry attempts. Do NOT push code that fails verification.

Step 4: Post Replies and Push

4a. Post all replies

• Template: Done. [1-line what changed]. [Optional 1-line why]
• Post reply:

  gh api repos/{owner}/{repo}/pulls/<PR_NUMBER>/comments/<comment_id>/replies -f body="<reply>"
  

• All replies must include: ---\n*AI-assisted response via Claude Code*

4b. Push once

git push

4c. Verify push

• Confirm git log -1 --format='%H' matches git ls-remote origin <branch>
• If push cannot be verified, report the failure — replies have already been posted

Step 5: Summary

Show: total comments found, filtered out, addressed with code changes, replied to, requiring user input.

Return Value

• Summary table of comments processed by category
• Git push result confirming all changes are on the remote

Examples

1. Address reviews on current branch's PR:

   /openshift-developer:address-review-pr
   

2. Address reviews on a specific PR:

   /openshift-developer:address-review-pr 1234
   

3. Preview mode:

   /openshift-developer:address-review-pr 1234 --preview
   

Arguments

• $1: PR number (optional — uses current branch if omitted)
• --preview: Preview each comment's proposed action and reply before proceeding

Duplicate Prevention

Before posting ANY reply, verify you haven't already responded:

python3 ${CLAUDE_SKILL_DIR}/scripts/check_replied.py <owner> <repo> <pr_number> <comment_id> --type <type>

Where <type> is one of: issue_comment, review_thread, or review_comment

Exit code 1: Skip — already replied. Exit code 2: Check failed — do NOT post a reply.

Response Rules

1. One response per feedback: Inline review comments reply inline only. General PR comments reply as general comment only. NEVER both.
2. Code changes require explicit request: Only modify code for imperative language ("change", "fix", "remove"). For questions — reply with explanation only.
3. Check before acting: Questions ("Why did you...?") get explanations, not code changes.