Pr Comments

ASSUMES

• PR comments already exist (this is addressing feedback, not collecting it)
• You have gh CLI and appropriate GitHub access
• Code changes have been made and pushed (you're replying, not fixing)

STANDARD PATH

1. Fetch All Unresolved Comments

ctx=$(${CLAUDE_PLUGIN_ROOT}/skills/shared/resolve-github-context.sh {number})
owner_repo=$(echo "$ctx" | jq -r '"\(.owner)/\(.repo)"')
${CLAUDE_PLUGIN_ROOT}/skills/shared/fetch-pr-context.sh "$owner_repo" {number}

The script returns comments with resolved status. Filter to unresolved only.

2. Triage Each Comment

For each unresolved comment:

• fix needed → Already fixed? → Reply with: "Fixed — [what changed]"
• already fixed → Reply: "Addressed in [commit] — [brief explanation]"
• acknowledged → Reply: "Noted — [reasoning]. Tracked in #NNN" (with issue link)

3. Reply in Thread

Use comment ID to reply in-thread via GitHub API:

${CLAUDE_PLUGIN_ROOT}/skills/pr-comments/reply-to-comment.sh {owner}/{repo} {number} {comment_id} 'Fixed — [explanation]'
```text

**Never:** `gh pr comment {number} --body='...'` (loses thread context)
**Never:** `gh api .../pulls/comments/{id}/replies` (endpoint does not exist, returns 404)
**Never:** raw `gh api` for replies — always use the script (validates correct PR)

### 4. Summary

Report:

- Fixed: X comments
- Already fixed: Y comments
- Acknowledged: Z comments
- Any unaddressed items

## EDGE CASES

- [Batch replies for same reviewer] — Read DETAIL: Batching Comments (when to group, when to separate)
- [Multiple reviewers on same issue] — Read DETAIL: Multi-Reviewer Coordination (consistency)
- [Conflicting feedback] — Read DETAIL: Handling Conflicts (reconcile before replying)
- [Comment response templates] — Read DETAIL: Response Formats (fix/already-fixed/acknowledged patterns)

---

## DETAIL: Batching Comments

When a single reviewer has multiple comments:

### Batch Small Changes

Group 2-3 small comments into one reply if they're related:

```text
Fixed:
1. Added validation on line 45 (comment #1)
2. Extracted to utility function (comment #2)
Both validated locally before push.
```text

### Keep Complex Changes Separate

If responses are lengthy or unrelated, reply individually:

```text
Comment #1: Lengthy architectural discussion
Comment #2: Simple typo fix
→ Two separate replies (don't batch)
```text

### One Reply Per Thread

Multiple comments in the same thread (sub-conversation) → one reply addressing all.

---

## DETAIL: Multi-Reviewer Coordination

When multiple reviewers comment on same code:

### Consistency

Ensure responses are consistent across reviewers:

```text
Reviewer A: "Extract to function"
Reviewer B: "This function is hard to test"

✅ Unified response: "Extracted to utility and added tests"
❌ Different responses: Looks like we ignored one reviewer
```text

### Timing

Reply to all comments in the same push cycle. Don't reply to some, ignore others.

### Addressing Conflicts

If two reviewers disagree, reply:

```text
Good points from both. We've decided on approach X because [reasoning].
Link to GitHub issue for extended discussion if needed.
```text

---

## DETAIL: Handling Conflicts

If reviewer feedback contradicts design or project standards:

### Acknowledge Respectfully

```text
I understand the concern about [issue]. However, we're using pattern X
because [project constraint]. If you'd like to discuss alternatives,
let's open a separate issue.
```text

### Don't Dismiss

Even if you disagree, acknowledge the valid concern:

```text
❌ Bad: "That's not how we do things here"
✅ Good: "I see the readability concern. We've chosen approach X
         because [trade-off]. Happy to discuss in future PRs."
```text

### Link to Guidance

If feedback relates to project standards, link to CLAUDE.md or relevant docs:

```text
Good catch. This follows pattern documented in CLAUDE.md#section.
Let me know if the guidance is unclear.
```text

---

## DETAIL: Response Formats

### When Code Was Fixed

```text
Fixed — [one sentence what changed].

[If tests added: Also added tests for X.]
```text

**Example:**

```text
Fixed — Added null check before accessing user.email on line 45.
Also added test case for when user creation fails mid-transaction.
```text

### When Issue Was Already Fixed in Prior Commit

```text
This was addressed in [commit hash] — [brief explanation].
```text

**Example:**

```text
This was addressed in 3bc4e2a — Validation now happens in middleware
before request reaches the handler.
```text

### When Acknowledging but Deferring

```text
Acknowledged — [reason for deferring]. Tracked in #NNN.
```text

**Example:**

```text
Acknowledged — Migrating to async/await is valuable, but out of scope
for this PR. Tracked in #456 for next quarter.
```text

### When Asking for Clarification

```text
I want to make sure I understand. Can you clarify [specific question]?
```text

**Example:**

```text
I want to make sure I understand the concern. Are you concerned about
performance at scale, or the maintainability of this pattern in general?
```text

### When Declining Feedback

```text
I appreciate the suggestion. However, [reason why we're not doing this].
Let's discuss in [GitHub issue link] if you'd like to revisit.
```text

**Example:**

```text
I appreciate the suggestion to use immutable data structures. However,
we've benchmarked this code path and mutation is actually faster here.
See discussion in #789 for performance trade-off analysis.
```text

---

## IMPORTANT RULES

- **ALWAYS use the reply script** — `${CLAUDE_PLUGIN_ROOT}/skills/pr-comments/reply-to-comment.sh` validates correct PR before posting
- **NEVER use standalone `gh pr comment`** (loses thread context)
- **NEVER use raw `gh api` for replies** — the script prevents wrong-PR and wrong-endpoint mistakes
- **NEVER use `/pulls/comments/{id}/replies`** — this endpoint does not exist (404)
- **Reply AFTER push** — Confirm code is live
- **Reply to EVERY comment** — Don't leave gaps
- **Batch when appropriate** — Related small items can be grouped
- **Stay respectful** — Acknowledge concern even if declining feedback
- **Link guidance** — Reference CLAUDE.md or project docs when relevant

---

## RELATED

- `/review-pr` — Initial PR review and address feedback
- `/commit` — Create commits being replied to
- [GitHub REST API: Pull Request Comments](https://docs.github.com/en/rest/pulls/comments)