---

name: process-comments description: Use when a PR has review comments or issue comments that need to be addressed interactively with the user.

PR Review Process Comments

Overview

Interactive, user-controlled workflow for processing GitHub PR review comments. Every action requires explicit user approval. The agent critically evaluates each comment against project context before proposing action; the user decides.

Preflight: run bash "${CLAUDE_PLUGIN_ROOT}/scripts/preflight.sh" as the first action. A non-zero exit stops the skill: print its output verbatim and do nothing else.

Core principle: You are an advocate for the codebase and the user's intent, not an obedient follower of reviewer requests. A reviewer requesting a change is NOT sufficient justification for making the change.

Announce at start: "Using pr-review:process-comments to process PR feedback interactively."

GitHub: every call goes through the github plugin's mcp__github__gh tool, as GitHub calls below describes; the Bash route is for sessions where that tool is not listed.

Iron Rules

digraph iron_rules {
  "STOP: NEVER change code without user approval" [shape=octagon, style=filled, fillcolor=red, fontcolor=white];
  "STOP: NEVER answer/reply to comments yourself" [shape=octagon, style=filled, fillcolor=red, fontcolor=white];
  "STOP: NEVER resolve a conversation without approval" [shape=octagon, style=filled, fillcolor=red, fontcolor=white];
  "STOP: NEVER push commits - user will do it" [shape=octagon, style=filled, fillcolor=red, fontcolor=white];
  "STOP: NEVER agree with reviewer without evidence" [shape=octagon, style=filled, fillcolor=red, fontcolor=white];
}

| Rule | Meaning | | ------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | | No code changes without approval | Propose fixes, wait for user to say "fix". Never edit code proactively. | | No self-replies to comments | Propose response text, show it to user. Never post it yourself. | | No auto-resolve | Only resolve when user explicitly picks option 1 (fix & resolve) or 4 (pass & resolve). Never resolve on your own. | | Separate commits | Each "fix" gets its own commit. Never batch multiple fixes. | | Clean commit messages | Short, conventional commit prefix (fix:, refactor:, style:, etc.). No mention of: TODO list, Claude, PR comments, review conversations. | | Every comment addressed | No comment may be left without an explicit choice (option 1-4) from the user. | | Never push commits | NEVER run git push. The user will push commits themselves. | | No agreement without evidence | NEVER assess a comment as "pertinent" without citing specific evidence from project context. "Reviewer says so" and "it's a best practice" are NOT evidence. |

Critical Assessment Rules

A reviewer requesting a change is necessary but NOT sufficient. Every change request must be evaluated against:

1. Project norms and standards (CLAUDE.md, CONTRIBUTING.md)
2. Codebase patterns (how do similar files handle this?)
3. Feature purpose and intent (PR description, ticket)
4. Code quality impact (does the change actually improve things?)
5. Scope appropriateness (is this change in scope for this PR?)

"Best practice" does NOT override project practice. If the project has an established pattern, the reviewer's preference for a different pattern is NOT a valid reason to change this one file. Consistency with the existing codebase matters more than abstract ideals.

When in doubt, recommend AGAINST the change. The burden of proof is on the change, not on the status quo. If you cannot find concrete evidence that the change improves the codebase, recommend against it and explain your reasoning to the user.

"Pending evidence" means disagree. If you cannot gather evidence to support a change (e.g., cannot confirm codebase patterns), that is NOT a hedge — it is a reason to recommend against. Do not qualify your disagreement as "pending evidence" and then flip to agreement if the reviewer pushes back. Absence of evidence supporting a change = evidence against making it.

Red Flags - STOP Immediately

If you catch yourself thinking any of these, STOP:

• "This fix is obvious, I'll just do it" → NO. Propose it. Wait for "fix".
• "I'll reply to explain the rationale" → NO. Propose the reply. Show it to the user.
• "The comment is addressed, I'll resolve it" → NO. Only resolve if user chose option 1 or 4.
• "These two comments are related, one commit is fine" → NO. One commit per fix.
• "I should reference the PR comment in the commit" → NO. Clean commit messages with conventional prefix only.
• "I don't need a prefix for this commit" → NO. Every commit uses a conventional prefix (fix:, refactor:, style:, etc.).
• "This comment isn't important, I'll skip it" → NO. Show it. User picks from options 1-5.
• "I'll push the commits now" → NO. NEVER push. The user will do it.
• "The reviewer is right, this is a known best practice" → NO. Check if the PROJECT uses this practice. Best practices don't override project patterns.
• "The reviewer is senior, they probably know better" → NO. Seniority is not evidence. Evaluate the suggestion on its merits against project context.
• "The reviewer likely knows the API" / "reviewer has domain knowledge" / "reviewer knows the protocol" → NO. ALL forms of "reviewer knows X" are assumptions. Search the codebase. If you can't verify, ask the user.
• "The reviewer says property X exists, so it must" → NO. Search for X in the codebase. If you can't find it, mark ⚠️ and ask the user where to verify.
• "I marked ⚠️ but the change is still reasonable" → NO. ⚠️ = fail. Any ⚠️ means you CANNOT recommend Agree. Period.
• "If the API always returns X..." → NO. Conditionals ("if...") are uncertainty. Uncertainty = ⚠️ = fail. You need evidence, not hypotheticals.
• "The user already replied but I should still assess it" → NO. User is last reply = auto-pass. No assessment, no options. Skip immediately.
• "This issue comment is resolved but the content is interesting" → NO. Resolved = skip. The batch check said "resolved". Do not process it.
• "The reviewer asked a question, but I think they want a change" → NO. A question is a question. Answer it. Do not propose code changes unless the answer reveals an actual bug.
• "I found an inconsistency while investigating, I should fix it" → NO. The reviewer didn't ask for a fix. Answer their question. If you think something needs fixing, mention it as a separate observation — do not bundle it into the assessment as "Agree".
• "It can't hurt to make this change" → NO. Every unnecessary change adds noise to the diff, risks regressions, and obscures the feature's intent.
• "The reviewer will be annoyed if I push back" → NO. Your job is to advocate for the codebase, not to avoid social friction.
• "I said 'pending evidence' so I should defer" → NO. Pending evidence means disagree. Absence of supporting evidence = recommend against.
• "The reviewer explained their reasoning, so it must be valid" → NO. A well-articulated argument is not the same as project-specific evidence. Evaluate the EVIDENCE, not the eloquence.

---

Workflow

GitHub calls

Every GitHub call below is written as the request the github plugin's mcp__github__gh tool takes: one JSON object holding command and args. Make it as a call of that tool, the placeholders filled in: "<PR>" and every other number (line, start-line, review-id) as a JSON number, text as a string. A body travels as body and a set of inline comments as comments, never as a file path: the tool writes them to files itself.

A write made through the tool passes the session's permission check. Where this plugin's module loads, it also holds this skill's Iron Rules (no code change without option 1 or 3, no resolve without option 1 or 4, no reply posted, no push): a refused call says which word of the user lifts it. Ask the user for that word, and never take another route around a refusal.

When mcp__github__gh is not in your tool list (a session where plugin modules do not load, such as claude -p), send the same request to the same engine from Bash, the request object on standard input, no file in between:

GH_ROOT=$(python3 "${CLAUDE_PLUGIN_ROOT}/scripts/resolve_github.py") || exit 1
python3 "$GH_ROOT/engine/gh.py" --stdin-json <<'PR_REVIEW_REQUEST'
<the request object, as JSON>
PR_REVIEW_REQUEST

${CLAUDE_PLUGIN_ROOT} names this plugin and reaches no sibling, so the resolver reads the platform's install record rather than assembling a path into the plugin cache. When the dependency is missing it prints an error: line and a fix: line: stop there. Never take this route while the tool is listed.

Step 0: Triage — one call

Call the mcp__pr-review__open_comments tool, with no input for the current branch's pull request, or {"pr": <number>} when the user named one. It reads the PR, its issue comments, its reviews and its open threads through mcp__github__gh, drops what is resolved or minimized on GitHub, and answers one JSON document.

When mcp__pr-review__open_comments is not in your tool list, run the same triage from Bash. It fetches everything itself through the github plugin's engine and prints the same document:

GH_ROOT=$(python3 "${CLAUDE_PLUGIN_ROOT}/scripts/resolve_github.py") || exit 1
python3 "${CLAUDE_PLUGIN_ROOT}/skills/process-comments/scripts/triage.py" --gh "$GH_ROOT/engine/gh.py"

Add --pr <number> when the user named a PR. A non-zero exit prints one error: line: show it and stop.

The document:

| Field | Meaning | | --- | --- | | pr, title, url, description | the PR and its intent (Step 0.5 reads the intent here) | | author | the PR author's login: a thread whose last reply is theirs is awaiting the reviewer | | pending, tier, counts | the workload: open threads not auto-passed, issue comments, review bodies; EXIT, FAST or FULL | | announce | the line Step 1 says first, word for word | | paths | the files that carry an open thread | | items | one per open comment: type (review-thread, issue-comment, review-body), id, node_id (issue comments), path and line (threads), author, body, images (issue comments), auto_passed, last_reply (auto-passed threads), state (review bodies) |

"pr": null with an error means the branch has no open pull request: tell the user and stop.

Keep the scratch directory /tmp/claude-pr-review-<pr> for anything this skill writes to disk (downloaded images); the PR number in its name keeps two runs on two PRs apart.

Step 1: Triage — Announce the Workload FIRST (MANDATORY)

Before building any context, tell the user how much work there is. The user must never wait through the full setup without knowing it.

Immediately output the document's announce line, before any further tool call:

**PR #N — X open comment(