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

**Code-level comments (reviewThreads):**
1. **Exclude resolved threads**: Filter out threads where `isResolved: true`
2. **claude[bot] handling**: For `claude[bot]` comments, 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[bot] handling**: For `claude[bot]` reviews, 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[bot] handling**: Keep only the **last** `claude[bot]` comment
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**: Check existing PR comments by `claude[bot]` with "PR Review Overview" in the body. Count those to determine the current iteration number N.

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

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:

rune next [file] - get next task
rune progress [file] [id] - mark in-progress
Implement the fix
rune complete [file] [id] - mark complete
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:

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

9. Fix CI Issues

For each failed check:

Identify the failure type from check name and logs
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
Parse error output to identify specific failures
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
Re-run locally to verify fix
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 - Iteration ${N}

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

## Valid Issues (fixed)
...

## Invalid/Skipped Issues
...

## CI Status
...
EOF
)"

12. Commit, Push, and Verify

After all fixes:

Run full test suite locally
Run linter
Commit the code changes
Push to remote
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

pr-review-fixer

PR Review Fixer

Workflow

1. Fetch PR Comments