Agent Skills: PR Review Fixer

PR Review Fixer

Fetch unresolved PR comments, validate each issue, create a fix plan, implement fixes, and verify CI checks pass (tests, lint, build).

Workflow

1. Fetch PR Comments

# Get PR info
PR_NUM=$(gh pr view --json number --jq '.number')

# Get all PR comments via GraphQL (code-level AND PR-level)
gh api graphql -f query='
  query($owner: String!, $repo: String!, $pr: Int!) {
    repository(owner: $owner, name: $repo) {
      pullRequest(number: $pr) {
        # Code-level review comments (file/line specific)
        reviewThreads(first: 100) {
          nodes {
            id
            isResolved
            comments(first: 50) {
              nodes { id body author { login } path line }
            }
          }
        }
        # PR-level review comments (top-level review body)
        reviews(first: 50) {
          nodes {
            id
            body
            state
            author { login }
          }
        }
        # PR-level issue comments (general discussion)
        comments(first: 100) {
          nodes {
            id
            body
            author { login }
          }
        }
      }
    }
  }
' -f owner=OWNER -f repo=REPO -F pr=$PR_NUM

2. Filter Comments

A comment counts as a "Claude review" if either the author is claude[bot] (the upstream anthropics/claude-code-action Action) or the body contains the sentinel <!-- claude-local-review --> (emitted by the local-review agent when pr-pilot runs it locally). Apply the dedup rules below to both sources uniformly.

Code-level comments (reviewThreads):

1. Exclude resolved threads: Filter out threads where isResolved: true
2. Claude review handling: For Claude review comments (as defined above), keep only the last comment per thread
3. Group by file/location: Organize by path and line number

PR-level review comments (reviews):

1. Exclude empty bodies: Skip reviews with empty or whitespace-only body
2. Exclude approval-only: Skip reviews with state APPROVED and no actionable feedback
3. Claude review handling: For Claude reviews (as defined above), keep only the most recent one

PR-level issue comments (comments):

1. Exclude bot noise: Skip automated comments (CI bots, etc.) unless actionable
2. Claude review handling: Keep only the last Claude review comment (as defined above)
3. Identify actionable items: Look for requested changes, questions, or suggestions

3. Determine Working Location

Nothing from this skill is written into the repo. Review reports go out as PR comments, and the rune task file lives in a system temp directory.

Working directory: /tmp/pr-review-${PR_NUM}/. Create it if needed. Never write under the repo (no .claude/reviews/, no report files beside the code).

Iteration tracking: Count existing PR comments whose body contains the sentinel <!-- pr-review-overview --> (or, for legacy comments posted before the sentinel existed, comments authored by claude[bot] with "PR Review Overview" in the body). The count gives you the current iteration number N. The sentinel is required because gh pr comment posts under the local user account, not claude[bot], so an author check alone misses every iteration when this skill runs outside the upstream Action.

4. Validate Issues

Code-level comments:

1. Read the referenced code at path:line
2. Evaluate: Is issue still present? Is suggestion correct? Does it align with project conventions?
3. Mark as valid or invalid with brief rationale

PR-level comments:

1. Parse the comment for actionable items (suggestions, questions, requested changes)
2. Check if the feedback applies to current PR state (changes may have been made since)
3. Evaluate: Is the request reasonable? Does it align with project goals?
4. Mark as valid or invalid with brief rationale
5. Skip pure acknowledgments, thanks, or informational comments without action items

5. Prepare Review Overview

Assemble the review overview in-context (not on disk). Step 11 posts the final version — including CI status from step 9 — as a PR comment. Use this structure:

# PR Review Overview - Iteration [N]

**PR**: #[number] | **Branch**: [name] | **Date**: [YYYY-MM-DD]

## Valid Issues

### Code-Level Issues

#### Issue 1: [title]
- **File**: `path:line`
- **Reviewer**: @user
- **Comment**: [quoted]
- **Validation**: [rationale]

### PR-Level Issues

#### Issue 2: [title]
- **Type**: review comment | discussion comment
- **Reviewer**: @user
- **Comment**: [quoted]
- **Validation**: [rationale]

## Invalid/Skipped Issues

### Issue A: [title]
- **Location**: `path:line` or PR-level
- **Reviewer**: @user
- **Comment**: [quoted]
- **Reason**: [why invalid]

6. Create Task List

Use rune to create the task file under the temp working directory from step 3 — never in the repo:

WORK_DIR="/tmp/pr-review-${PR_NUM}"
mkdir -p "${WORK_DIR}"
TASK_FILE="${WORK_DIR}/review-fixes-${N}.md"

rune create "${TASK_FILE}" --title "PR Review Fixes - Iteration ${N}"

# Add tasks via batch for efficiency
rune batch "${TASK_FILE}" --input '{
  "operations": [
    {"type": "add", "title": "Fix: [issue 1]"},
    {"type": "add", "title": "Fix: [issue 2]"}
  ]
}'

7. Fix Issues

Loop through tasks:

1. rune next [file] - get next task
2. rune progress [file] [id] - mark in-progress
3. Implement the fix
4. rune complete [file] [id] - mark complete
5. Repeat until done

8. Check CI Status

After fixing review comments, verify CI checks:

# Get check status for the PR
gh pr checks --json name,state,conclusion

# For failed checks, get details
gh run view [RUN_ID] --log-failed

Check types to handle:

1. Test failures: Parse test output, identify failing tests, fix code or tests
2. Lint errors: Run linter locally, fix reported issues
3. Type errors: Run type checker, fix type mismatches
4. Build failures: Check build logs, fix compilation issues

9. Fix CI Issues

For each failed check:

1. Identify the failure type from check name and logs
2. Run locally to reproduce:
   • Tests: make test or project's test command
   • Lint: make lint or project's lint command
   • Types: make typecheck or equivalent
3. Parse error output to identify specific failures
4. Fix the issues:
   • For test failures: Check if test expectations need updating or if code has a bug
   • For lint errors: Apply automatic fixes where possible, manual fixes otherwise
   • For type errors: Add/fix type annotations or fix type mismatches
5. Re-run locally to verify fix
6. Add to task list if not already tracked

Test failure handling:

Run the project's test command and read the output directly — do not tee to a file in the repo. Examples: make test, pytest --tb=short, go test ./.... If you need to persist output across commands, use ${WORK_DIR}/test-output.txt (the temp path from step 3), not a path in the repo.

Parse output for:

• Failed test names and locations
• Assertion errors with expected vs actual values
• Stack traces pointing to failure source

10. Resolve Fixed Threads

After fixing code-level issues, resolve the corresponding review threads on GitHub:

# For each fixed code-level thread, resolve it using its thread ID
gh api graphql -f query='
  mutation($threadId: ID!) {
    resolveReviewThread(input: {threadId: $threadId}) {
      thread { isResolved }
    }
  }
' -f threadId=THREAD_NODE_ID

Only resolve threads whose issues were validated and fixed. Do not resolve threads that were skipped or marked invalid — those need human attention.

11. Post Review Report as PR Comment

Compose the final overview here — using the structure from step 5, plus the CI status from step 9 — and post it directly with gh pr comment. Do not stage the body in a file first; pass it inline. Example:

gh pr comment "$PR_NUM" --body "$(cat <<EOF
<!-- pr-review-overview -->
# PR Review Overview - Iteration ${N}

**PR**: #${PR_NUM} | **Branch**: ${BRANCH} | **Date**: $(date +%Y-%m-%d)

## Valid Issues (fixed)
...

## Invalid/Skipped Issues
...

## CI Status
...
EOF
)"

The leading <!-- pr-review-overview --> sentinel is what the iteration counter in step 3 matches on. Without it, N will not increment between rounds when this skill is invoked locally.

12. Commit, Push, and Verify

After all fixes:

1. Run full test suite locally
2. Run linter
3. Commit the code changes
4. Push to remote
5. Monitor CI status to confirm checks pass

Nothing from /tmp/pr-review-${PR_NUM}/ belongs in the commit — those paths are outside the repo and git will ignore them automatically.

Key Behaviors

• Auto-fix: Fix all validated issues without pausing for approval
• Context preservation: Keep diff_hunk context when analyzing
• Convention adherence: Follow project's existing patterns
• Deduplication: Consolidate multiple comments on same issue into one task
• CI verification: Always check CI status after fixing review comments
• Local reproduction: Run tests/linters locally before pushing fixes
• Reports as comments: Post review reports as PR comments, never write them to disk under the repo
• No in-repo working files: Rune task files and any captured output live under /tmp/pr-review-${PR_NUM}/, not in the repo