| name | address-pr-comments |
| description | Fetch PR review comments from GitHub, interactively walk through each one, and choose how to address it — fix the code, reply, ask for clarification, or skip. Use when you have PR feedback to work through. |
Address PR Comments
Interactive skill for triaging and addressing GitHub PR review comments one by one.
Step 1: Identify the PR and repo
1a. Resolve the repository
The gh CLI default repo may differ from the actual working directory repo. Always derive the repo from git:
git remote get-url origin
Parse owner/repo from the URL (handles both git@github.com:Owner/Repo.git and https://github.com/Owner/Repo.git). Use this as REPO for all gh api calls via --repo flag or explicit URL paths.
1b. Resolve the PR number
Use this priority order:
- Argument: if the user passed a number (e.g.,
/address-pr-comments 955), use it directly
- Current branch: check if the current branch has an open PR:
gh pr view --repo REPO --json number,title,state --jq 'select(.state=="OPEN")'
- Ask the user: if neither works, use AskUserQuestion to request the PR number
1c. Fetch comments
Fetch inline review comments (code-level):
gh api repos/OWNER/REPO/pulls/PR_NUMBER/comments
Fetch general conversation comments (non-inline):
gh api repos/OWNER/REPO/issues/PR_NUMBER/comments
Fetch review submissions — these carry the review body (the top-level summary a reviewer writes when submitting a review), which is distinct from inline comments and is otherwise missed:
gh api repos/OWNER/REPO/pulls/PR_NUMBER/reviews
Treat every review entry whose body is non-empty as a comment to triage. Its id is the review_id used for replies. Ignore reviews with an empty body (they only carry inline comments, which are already fetched above).
Also fetch PR metadata for context:
gh pr view PR_NUMBER --repo OWNER/REPO --json number,title,author,headRefName,state
Step 2: Parse and group comments
A "comment" in this skill means any of three things:
- Inline review comment — tied to a file and line (from
/pulls/{pr}/comments)
- Conversation comment — general PR-level (from
/issues/{pr}/comments)
- Review body — the top-level summary attached to a review submission (from
/pulls/{pr}/reviews, when body is non-empty)
Group comments by:
- File + line for inline review comments
- Conversation thread — group replies together, show only the root comment for triage
- Review body — one entry per review with a non-empty body (no file/line; tag as
Review)
- Author — note who left the comment
Skip:
- Self-comments — match against
git config user.name and the PR author login (applies to inline, conversation, and review bodies)
- Reply comments — comments with
in_reply_to_id set (these are thread replies, shown under their parent)
- Empty review bodies — reviews whose
body is empty/null (they only carry inline comments)
- Unselected bot comments — see bot filtering below
Bot comment filtering
Bot authors have a type field of "Bot" in the GitHub API response. If any bot comments are detected:
- List the distinct bot names and their comment counts (e.g.,
coderabbitai[bot] — 7 comments)
- Use AskUserQuestion to ask which bots to include, with options like:
- Include all bots
- Include [bot1] only (one option per bot, if ≤ 3 bots)
- Exclude all bots
- Filter comments according to the user's choice
If no bot comments exist, skip this step silently. Tag included bot comments with the bot name in the summary table so the user can distinguish human vs. bot feedback.
Sort by file path, then line number, so related comments are addressed together.
Step 3: Show summary
Before starting the interactive loop, show a summary:
## PR #123 — 12 comments to address
| # | File | Line | Author | Preview |
| --- | ------------------------ | ---- | --------- | ------------------------------ |
| 1 | src/module/service.ts | L42 | reviewer1 | "This should use BigNumber..." |
| 2 | src/module/controller.ts | L15 | reviewer2 | "Missing validation for..." |
| 3 | _(Review summary)_ | — | reviewer3 | "Nice fix — a couple items..." |
| ... | | | | |
Ready to walk through each comment.
For review-body entries, use _(Review summary)_ (or similar) in the File column and — in the Line column so they stand out from inline comments.
Step 4: Interactive loop — one comment at a time
For each comment, present it in full, then use AskUserQuestion to let the user choose how to handle it.
4a. Present the comment
Show:
- The full comment text (including any code suggestions from the reviewer)
- The file and line number (omit for review bodies — they have no anchor)
- The surrounding code (read ~10 lines around the referenced line; skip for review bodies)
- Any thread replies beneath the root comment
For review bodies, the body often contains multiple distinct points (numbered or bulleted). Parse those out and address each point in turn during the Round 1 / Round 2 flow, rather than treating the whole review body as one atomic comment. If a point cites a specific file/line in prose (e.g., "xrpl/wallet/wallet.go:144-146"), read that file region as the "surrounding code" before presenting it.
4b. Ask the user what to do
Constraint: AskUserQuestion supports a maximum of 4 explicit options (plus an automatic "Other" free-text option). Use a two-round flow to fit all 5 actions.
Round 1 — present these 4 options:
| Option | What happens |
|---|
| Explain more | Provide a detailed explanation of the issue: what the reviewer is pointing out, why it matters, what the current code does vs. what the suggestion would change, and the concrete risks or benefits. After explaining, re-ask with Round 2 options. |
| Fix it | Read the relevant code, understand the reviewer's suggestion, apply the fix, then draft a short reply confirming the fix (e.g., "Fixed in [commit]" or "Good catch, updated.") |
| Reply | Proceed to Round 2 to choose the reply type. |
| Skip | Move to the next comment without action. |
Round 2 (Reply) — if the user picks "Reply", ask a follow-up:
| Option | What happens |
|---|
| Current approach is correct | Draft a reply explaining why the current code is intentional. Show the draft to the user for approval before posting. |
| Ask for clarification | Draft a reply asking the reviewer to elaborate. Show the draft for approval. |
Round 2 (after Explain more) — re-present the action options without "Explain more":
| Option | What happens |
|---|
| Fix it | Same as Round 1 |
| Reply | Proceed to reply type selection |
| Skip | Move to the next comment |
Explain more
When the user picks "Explain more":
- Read the referenced file and broader context (~50 lines around the comment)
- Research the topic — check related files, production code, documentation, or similar patterns in the codebase
- Explain clearly:
- What the reviewer is pointing out — restate the issue in plain terms
- What the current code does — walk through the relevant logic
- What the suggestion would change — concrete before/after behavior
- Risks of not fixing — what could go wrong in practice
- Risks of fixing — any potential side effects of the suggested change
- After the explanation, re-present Round 2 action options (Fix / Reply / Skip) without the "Explain more" option
4c. Execute the chosen action
Fix it
- Read the file at the referenced line (broader context: ~30 lines around it)
- Understand what the reviewer is asking for
- Apply the code fix using Edit
- Show the diff to the user for confirmation
- Draft a reply: "Fixed — [brief description of what changed]."
- Store the reply for later (do NOT post yet)
Reply — current approach is correct
- Read the file to understand the full context
- Draft a concise, professional reply explaining the rationale
- Show the draft to the user via AskUserQuestion with options: "Post as-is", "Edit before posting" (Other option covers this), "Skip"
- Store the approved reply for later
Ask for clarification
- Draft a question that references the specific code and asks what the reviewer would prefer
- Show the draft for approval (same flow as above)
- Store the approved reply for later
Step 5: Summary and batch post
After all comments are processed, show a recap:
## Summary
| # | Comment | Action | Reply draft |
| --- | ------------------------------ | ------- | ---------------------------------- |
| 1 | "This should use BigNumber..." | Fixed | "Fixed — switched to BigNumber.js" |
| 2 | "Missing validation for..." | Reply | "This is validated upstream in..." |
| 3 | "Consider extracting..." | Skipped | — |
| ... | | | |
Code changes: 3 files modified
Replies ready: 8 drafts
Then ask:
| Option | What happens |
|---|
| Post all replies | Post every drafted reply to the PR using gh api |
| Post replies one by one | Show each reply and confirm before posting |
| Save replies only | Don't post — just keep the drafted text for the user to post manually |
| Discard replies | Don't post anything |
Posting replies
For inline review comments, reply to the specific comment thread:
gh api repos/{owner}/{repo}/pulls/<pr>/comments/<comment_id>/replies -f body="<reply>"
For general conversation comments and review bodies, post a new conversation comment (GitHub has no "reply to review summary" endpoint, so the convention is a fresh PR-level comment; quote or reference the review when helpful):
gh api repos/{owner}/{repo}/issues/<pr>/comments -f body="<reply>"
Rules
- Never post a reply without user approval. Always show drafts first.
- Never modify code without showing the diff. The user must see what changed.
- Keep replies professional and concise. No emojis, no fluff. Match the tone of the reviewer.
- Group related comments. If two comments are about the same issue in the same file, address them together.
- Respect reviewer suggestions. When GitHub suggestion syntax is used (
suggestion blocks), extract the exact suggested code for the fix.
- Track what was done. Maintain a running list of actions taken so the final summary is accurate.
