pr-review-fixer

What this skill does

# 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

```bash
# 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:

```markdown
# 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:

```bash
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:

```bash
# 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:

```bash
# 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:

```bash
gh pr comment "$PR_NUM" --b