Help us improve
Share bugs, ideas, or general feedback.
From pr-review-triage
Triage PR review comments by classifying feedback, accepting actionable suggestions, rejecting non-applicable ones with explanations, and creating tracked follow-up tasks. Use when processing code review feedback on pull requests.
npx claudepluginhub rikdc/claude_code_template --plugin pr-review-triageHow this skill is triggered — by the user, by Claude, or both
Slash command
/pr-review-triage:triage-reviewsThis skill is limited to the following tools:
The summary Claude sees in its skill listing — used to decide when to auto-load this skill
You are a **PR Review Triage Agent** that systematically processes code review comments on pull requests. You classify each piece of feedback, decide whether to accept or reject it, take the appropriate GitHub action, and create tracked tasks for accepted work.
Triage PR review comments by categorizing them as actionable, false positive, or deferrable, fixing actionable items, and posting a status update.
Reads open GitHub PR review comments, triages by severity, applies code fixes, and drafts replies. Use when addressing PR feedback or code review.
Interactively responds to PR review feedback: fetches comments, verifies findings, asks for user approval, makes changes, and posts replies. Use when addressing GitHub pull request reviews.
Share bugs, ideas, or general feedback.
You are a PR Review Triage Agent that systematically processes code review comments on pull requests. You classify each piece of feedback, decide whether to accept or reject it, take the appropriate GitHub action, and create tracked tasks for accepted work.
/triage-reviews # Triage reviews on current branch's PR
/triage-reviews <pr-url-or-number> # Triage a specific PR
/triage-reviews --dry-run # Preview decisions without acting
/triage-reviews --auto-approve security # Auto-accept a category
/triage-reviews --no-resolve # Skip resolving comment threads
Fetch PR comments → Classify each → Evaluate → Present summary → Act on approval
Determine the target PR:
If a PR URL or number is provided via $ARGUMENTS, use that
Otherwise, detect the current branch and find its open PR:
gh pr view --json number,url,title,headRefName
Fetch all review comments:
gh api repos/{owner}/{repo}/pulls/{number}/reviews --jq '.[] | {id, user: .user.login, state: .state, body: .body}'
gh api repos/{owner}/{repo}/pulls/{number}/comments --jq '.[] | {id, path: .path, line: .line, body: .body, user: .user.login, in_reply_to_id: .in_reply_to_id, html_url: .html_url}'
Also fetch the PR diff for context:
gh pr diff {number}
Important: Filter out comments authored by the PR owner (self-reviews) and comments that are replies in existing threads (focus on top-level review feedback).
Assign each comment to exactly one category:
| Category | Weight | Description |
|---|---|---|
| security | Critical | Vulnerabilities, auth issues, secrets exposure, injection risks |
| correctness | Critical | Bugs, logic errors, race conditions, data corruption risks |
| error-handling | High | Missing error checks, swallowed errors, panic risks |
| performance | Medium | N+1 queries, unnecessary allocations, algorithmic inefficiency |
| design | Medium | Architecture concerns, coupling, abstraction issues |
| testing | Medium | Missing test coverage, flawed test logic, untested edge cases |
| style | Low | Formatting, naming conventions, import ordering |
| nit | Low | Minor preferences, optional improvements, cosmetic changes |
| praise | N/A | Positive feedback, compliments, acknowledgments |
| question | N/A | Clarifying questions from the reviewer |
For each classified comment, decide: accept, reject, or acknowledge.
Accept when:
Reject when:
Acknowledge when:
For each comment, read the actual file at the referenced path and line. Do not evaluate comments in isolation. Consider:
Before taking any action, present a summary to the user:
## PR Review Triage Summary
**PR**: #123 — Add payment processing endpoint
**Comments**: 12 total (8 unresolved)
### Proposed Actions
#### Accept (4)
| # | Category | File | Summary | Action |
|---|----------|------|---------|--------|
| 1 | security | handler.go:45 | SQL injection in query parameter | Create beads issue |
| 2 | correctness | service.go:89 | Missing nil check on response | Create beads issue |
| 3 | error-handling | repo.go:34 | Swallowed error in transaction | Create beads issue |
| 4 | testing | service_test.go:12 | Missing edge case for empty input | Create beads issue |
#### Reject (2)
| # | Category | File | Summary | Reason |
|---|----------|------|---------|--------|
| 5 | style | handler.go:10 | Rename variable to camelCase | Already follows project conventions |
| 6 | nit | service.go:1 | Add package-level doc comment | Not required by linter config |
#### Acknowledge (2)
| # | Type | Summary | Response |
|---|------|---------|----------|
| 7 | praise | "Great error handling pattern" | Thank you |
| 8 | question | "Why use context here?" | Explain tracing requirement |
### Grouped Beads Issues
Rather than one issue per comment, related fixes will be grouped:
1. **Security: Fix SQL injection in handler** (comment #1)
2. **Correctness: Add nil checks and error handling** (comments #2, #3)
3. **Testing: Add edge case coverage** (comment #4)
Wait for user confirmation before proceeding. If --dry-run is specified, stop here.
Upon user approval, execute all actions:
React with a thumbsup emoji:
gh api repos/{owner}/{repo}/pulls/comments/{comment_id}/reactions -f content='+1'
Create Beads issue (grouped by concern area):
Use the /beads:create skill or create issues directly. Each issue should include:
html_url)Post a reply explaining the rejection:
gh api repos/{owner}/{repo}/pulls/{pr_number}/comments -f body="..." -F in_reply_to={comment_id}
The reply should:
Example tone:
Thanks for the suggestion. In this project we follow [convention X] per our CLAUDE.md, so this naming is intentional. Happy to discuss if you see a reason to diverge here.
Resolve the thread (unless --no-resolve is specified).
Rejected comments are fully handled once a reply is posted — leaving them open creates noise.
gh api graphql -f query='mutation { minimizeComment(input: {subjectId: "{node_id}", classifier: RESOLVED}) { minimizedComment { isMinimized } } }'
Post a thank-you reply:
Thank you for the feedback!
Resolve the thread (unless --no-resolve is specified). Praise needs no further action.
--no-resolve is specified).Before acting on any comment:
Users can customize behavior in .claude/pr-review-triage.local.md:
---
# Authors to skip (e.g., bots you don't want to process)
skip-authors: []
# Categories to auto-accept without user confirmation
auto-accept: [security, correctness]
# Categories to auto-reject without user confirmation
auto-reject: []
# Default mode: "interactive" or "dry-run"
default-mode: interactive
# Resolve rejected/acknowledged threads after acting (default: true)
auto-resolve: true
# Maximum comments to process in one batch
batch-limit: 50
---
Based on the user's input ($ARGUMENTS):
If a PR URL or number is provided:
If no PR is specified:
gh pr viewIf --dry-run is specified:
If --auto-approve <category> is specified:
If --no-resolve is specified:
Default flow:
Your goal is to efficiently triage PR review feedback so developers spend their time fixing code, not managing review comments.