From rt
Reviews GitHub PR comments by verifying against current code, categorizes issues, replies with reasoning, implements fixes, and resolves threads in one pass.
npx claudepluginhub richtabor/agent-skills --plugin rtThis skill uses the workspace's default tool permissions.
Fetch, evaluate, and address PR review comments from GitHub. Many reviewer comments reference outdated code or misunderstand the logic — always verify against the actual codebase before acting.
Triages PR review comments by filtering false positives (outdated, misread, wrong context, style preference), validating against current diff, and fixing actionable ones with per-fix confirmation.
Reads open GitHub PR review comments, triages by severity and type, applies code fixes, and drafts replies. Use for addressing review feedback.
Respond to pull request review feedback interactively, working through each item with verification and code changes. Use when the user wants to address PR review comments.
Share bugs, ideas, or general feedback.
Fetch, evaluate, and address PR review comments from GitHub. Many reviewer comments reference outdated code or misunderstand the logic — always verify against the actual codebase before acting.
This is a single-pass flow. Fetch comments, read files, evaluate, present assessment, reply to all comments, resolve all threads, and show the final summary — all without pausing for user confirmation.
If no PR number is provided, find the PR for the current branch:
gh pr list --head $(git branch --show-current) --json number,title --jq '.[0]'
Fetch comments with their IDs:
gh api repos/{owner}/{repo}/pulls/{number}/comments --jq '.[] | {id: .id, path: .path, line: (.line // .original_line), body: .body, in_reply_to_id: .in_reply_to_id}'
Filter to only top-level comments (where in_reply_to_id is null).
Before evaluating any comment, read the actual current code. Reviewers often:
For each unique file path, read the file and verify:
Categorize each comment:
| Category | Criteria | Response |
|---|---|---|
| Already addressed | Issue was fixed in a subsequent commit, or reviewer misread the code | Explain what the code actually does |
| Fix | Valid bug, security issue, or typo that exists in current code | Implement the fix |
| Won't fix | Over-engineering, style preference, feature request, or would break consistency | Explain reasoning |
Do all of this in one pass — no pausing for user confirmation. Present your assessment, reply to each comment, and resolve all threads immediately.
Present ALL comments with your assessment:
## PR #[number]: [title]
Found [X] review comments. Here's my assessment:
---
### 1. `path/file.ts:42` — **Already addressed**
> [comment body]
**Issue**: Reviewer concerned about X
**Actual code**: Lines 26-34 already handle this — [brief explanation]
---
### 2. `path/other.ts:15` — **Won't fix**
> [comment body]
**Issue**: Reviewer wants X
**Why skip**: [Over-engineering / Matches existing pattern / Feature request / etc]
---
### 3. `path/file.ts:88` — **Fix**
> [comment body]
**Issue**: Typo in user-facing string
**Proposed change**: Change "Jumpope" to "Jump Rope"
---
## Summary
- **Already addressed**: 6 comments
- **Won't fix**: 8 comments
- **Fix**: 2 comments
Then immediately reply to all comments and resolve all threads (steps 6-7 below). Don't wait for user input.
For Already addressed comments, reply explaining the current state:
gh api repos/{owner}/{repo}/pulls/{pr_number}/comments/{comment_id}/replies \
-X POST \
-f body="This is already handled — lines 26-34 fetch the authenticated user and verify user.id === state before proceeding. If they don't match, it rejects with a CSRF error."
For Won't fix comments, reply with concise reasoning:
gh api repos/{owner}/{repo}/pulls/{pr_number}/comments/{comment_id}/replies \
-X POST \
-f body="Won't fix — this matches the exact pattern used for the other integrations in the same file. Changing just this one would be inconsistent."
For Fix comments, implement the fix first, then reply:
gh api repos/{owner}/{repo}/pulls/{pr_number}/comments/{comment_id}/replies \
-X POST \
-f body="Fixed in abc1234"
First, get all unresolved thread IDs:
cat << 'QUERY' | gh api graphql --input - --jq '.data.repository.pullRequest.reviewThreads.nodes[] | select(.isResolved == false) | {threadId: .id, commentId: .comments.nodes[0].databaseId}'
{"query": "query($owner: String!, $repo: String!, $pr: Int!) { repository(owner: $owner, name: $repo) { pullRequest(number: $pr) { reviewThreads(first: 100) { nodes { id isResolved comments(first: 1) { nodes { databaseId } } } } } } }", "variables": {"owner": "OWNER", "repo": "REPO", "pr": 123}}
QUERY
Then resolve each thread by ID:
cat << 'QUERY' | gh api graphql --input -
{"query": "mutation { resolveReviewThread(input: {threadId: \"THREAD_ID_HERE\"}) { thread { isResolved } } }"}
QUERY
After replying and resolving, show the final summary:
## Review Complete
All 16 conversations resolved.
### Already addressed (6)
| Comment | Explanation |
|---------|-------------|
| State validation | Already validates user.id === state at lines 26-34 |
| HR zones docs | Comments already say "milliseconds", not "percentage" |
### Won't fix (8)
| Comment | Reason |
|---------|--------|
| Form semantics | Matches existing pattern for other integrations |
| Rate limiting | Self-heals on next cron run, over-engineering |
### Fixed (2)
| Commit | Fix |
|--------|-----|
| `abc123` | Fixed typo "Jumpope" → "Jump Rope" |
Important: The entire flow (assess → reply → resolve → summarize) happens in one pass. Don't pause to ask "should I proceed?" — just do it.
Common patterns where the reviewer is wrong:
Response template:
"This is already handled — [specific location] does [what it does]. [Brief explanation of why it's correct]."
Only fix issues that:
| Reason | Response template |
|---|---|
| Matches existing pattern | "Won't fix — this matches the exact pattern of X, Y, and Z in the same file. Changing just this would be inconsistent." |
| Over-engineering | "Won't fix — [the failure mode] will fail obviously / self-heal on retry / is handled by [existing mechanism]." |
| Feature request | "Won't fix — this is a feature request rather than a bug. The current flow works: [what it does]. Out of scope for this PR." |
| Product decision | "Won't fix — this is a product decision, not a bug. [Current behavior] is intentional because [reason]." |
| Would break things | "Won't fix — this would break [existing behavior / consistency with X]." |
Reviewers often misread boolean logic. Example:
// "Refresh if expires in less than 5 minutes"
if (expiry.getTime() - Date.now() > 5 * 60 * 1000) {
return integration.access_token!; // Token is fresh, return early
}
// Proceed to refresh...
Reviewer says: "Condition is inverted, tokens never refresh" Reality: Condition is correct — returns early when fresh, refreshes when stale.
Reviewer says: "State parameter not validated" Reality: Lines 26-34 already validate it. Always check if the validation exists before agreeing.
Reviewer says: "Sensitive tokens logged in error messages" Reality: The error logs the API's error response, not our tokens. Read what's actually in the error string.
Reviewer references line 174, but file only has 161 lines. The file has changed since the review.