pr-comment-handler

PR Comment Handler

Process review comments on a pull request end-to-end: analysis, response, fixes, and learning capture.

Input

• PR number, URL, or current branch (defaults to current branch if omitted)

---

Step 1: Fetch Comments

gh pr view <PR_NUMBER> --json number,title,headRefName
gh api repos/<OWNER>/<REPO>/pulls/<PR_NUMBER>/comments
gh api repos/<OWNER>/<REPO>/pulls/<PR_NUMBER>/reviews

---

Step 2: Evaluate Comments

For each comment, run proposal-evaluator to produce a principled verdict before acting. Do not assume every comment requires a code change.

Quick triage first — classify to decide whether to evaluate or fast-track:

Category	Description	Next step
Already resolved	Addressed in a later commit	Reply "Resolved in <commit>", skip evaluator
Factual fix	Clear bug or broken code with no ambiguity	Accept immediately, note rationale
Needs evaluation	Opinion, suggestion, stylistic, or disputed	Run proposal-evaluator

For "Needs evaluation" comments, run the full 5-axis evaluation:

See proposal-evaluator skill for the scoring rubric and verdict template.

The evaluation produces one of:

• Accept → implement and reply
• Counter → implement your alternative and explain why
• Defer → do not change code; acknowledge and link to follow-up issue if warranted
• Decline → do not change code; reply with clear reasoning

Priority order: Already resolved → Factual fix → Evaluate others

---

Step 3: Apply Fixes

For each Factual fix comment and each Accept or Counter verdict from Step 2:

1. Locate the referenced file and line
2. Apply the fix following project conventions (CLAUDE.md)
3. Run quality checks relevant to changed files (lint, type-check)
4. Stage the fix: add files individually (avoid git add .)
5. Commit with reference to the review:

   fix: address review comment - <short description>
   

---

Step 4: Reply to Comments

Reply to each comment on GitHub:

gh api repos/<OWNER>/<REPO>/pulls/<PR_NUMBER>/comments/<COMMENT_ID>/replies \
  -f body="<reply text>"

Reply patterns:

• Accept: "Fixed in <commit-sha>. [Brief explanation of what changed]"
• Counter: "I took a different approach: [explanation]. This handles [concern] by [method]."
• Defer: "Valid point — deferred to [Issue] to keep this PR focused."
• Decline: "[Reasoning]. Happy to discuss further if you see it differently."

---

Step 5: Save Learnings to Memory

After handling all comments, abstract reusable patterns and save to memory:

What to save:

• Recurring feedback patterns
• Project-specific conventions revealed by review
• Anti-patterns to avoid going forward

What NOT to save:

• One-off fixes specific to this PR
• Ephemeral context

---

Step 6: Push and Notify

git push origin <branch>

---

Quick Reference

User Input	Action
Handle PR comments	Execute all steps for current branch PR
Handle PR comments #123	Execute all steps for PR #123
Reply to comments only	Steps 2 and 4 only (no code changes)

---

Notes

• Do NOT merge the PR — leave that to the user
• For ambiguous comments, ask the user before making assumptions
• Commit each logical fix separately for clean history

Related Skills

• proposal-evaluator — 5-axis evaluation framework used in Step 2

Gotchas

See gotchas.md in this directory for known pitfalls and recurring mistakes when using this skill.