Triage PR review comments

Pull the review feedback on your PR and, comment by comment, summarize it plainly, judge whether it holds up against the real code, and draft either a fix plan or a reasoned reply. Analysis and drafts only: it does not post anything or change code.

Step 1: Identify the PR

The current branch's PR by default, or a number/URL from $ARGUMENTS. No separate lookup is needed: Step 2 prints the title, base, and body along with the reviews.

Those state what this PR set out to do, which Step 3 judges scope against. If the body links an issue (CBRD, APIS, TOOLS, HHH), pull it too (jira-fetch for CUBRID Jira Server keys, publicly readable projects only) so the PR's intent comes from the issue, not from a guess.

Step 2: Fetch the reviews

bash ${CLAUDE_SKILL_DIR}/assets/fetch_reviews.sh [PR] [--include-resolved]

Merges inline code comments, review summaries, and PR-level comments (humans and bots, shown as (User) / (Bot)) with thread/reply info. Needs gh (authenticated) and jq.

Comments in resolved review threads are skipped: that discussion is already settled, so re-judging it wastes effort and reopens closed points. The script prints how many it skipped; pass --include-resolved when you do want to revisit them (say, to check that a resolved thread was actually addressed). Threads that are merely outdated (the diff moved) are still shown: outdated is not resolved. If $ARGUMENTS is a full PR URL, its owner/repo is used, so a URL from another repo is not read as the current directory's PR.

Step 3: Judge each comment on evidence, not on authority

Start neutral. A reviewer being senior, confident, a maintainer, or a bot is not evidence: bots especially produce false positives. Agreeing when the reviewer is wrong costs a pointless change and a wrong precedent; dismissing when they are right ships a defect. Judge every comment on two axes:

1. 사실 (is the claim true here?): open the referenced file:line and the diff and trace the real path. Look for evidence both ways: what would make the reviewer right, and what would refute them (an existing guard, a test that already covers it, a call site that cannot reach that state, a value the type system rules out). A comment survives only if you failed to refute it.
2. 범위 (is it this PR's job?): check the claim against the PR/issue intent from Step 1. A correct point that is outside what this PR set out to do is a follow-up issue, not a change to make here.

근거 기준: every 판정 needs at least one checkable thing, quoted in the output: the code itself (file:line), a manual or spec statement (cubrid-manual / cmt-manual, or the JDBC/JPA spec), or a run you actually did (test, query, log). These are not evidence: "일반적으로 그렇다", "리뷰어가 그렇게 말했다", 기억, 관례.

If the comment claims a bug, try to reproduce it (run the test, follow the code path) instead of reasoning about it. If you cannot verify it either way, do not guess: mark it 확인필요 and draft the question to ask the reviewer.

Step 4: Summarize and draft, per comment

For each comment, output (요약/판정/계획 or 답변 in Korean for the user):

• 요약: what the reviewer is asking, in plain Korean.
• 판정: one of the following, each with a one-line 근거 that quotes a file:line, a manual/spec statement, or a run result:
  • 타당(O): a real defect or a clear improvement, verified.
  • 부분(△): the observation holds but its premise, scope, or proposed fix is partly wrong. Say which part you take and which you push back on.
  • 부당(X): factually wrong, misread the code, or already handled. Name the refuting evidence.
  • 범위 밖(S): correct, but outside this PR's intent. Propose it as a follow-up issue instead.
  • 취향(P): a style preference with no correctness argument. Follow the project convention if one exists; otherwise mark it optional.
  • 확인필요(?): you could not verify it either way. Do not guess a verdict.
• 수정 계획 (타당·부분): which file and approach, briefly.
• 답변 초안 (부당·부분·범위 밖·확인필요): a reasoned reply to post. Write the reply in the reviewer's language (English for upstream repos such as Hibernate, Korean for CUBRID internal repos); keep the user-facing 요약/판정 in Korean.

If a reply needs to explain a non-trivial flow or relationship, an inline mermaid code block is an option (GitHub renders it in PR comments; nodes auto-size to text). Use it only when a diagram is clearer than a sentence.

Tone: open-source developer voice, plain and direct, not academic or formal-document. Lead a reply with the evidence, not with agreement: no "좋은 지적입니다" / "You're absolutely right" openers, and no conceding a point you just refuted to keep things pleasant. Disagreement is fine when it carries a reason; state it plainly and leave the decision to the reviewer. No em-dash (—): use commas, colons, parentheses, periods.

Step 5: Hand off (no posting, no fixing)

Give the user the per-comment triage. Do not post replies or edit code. If they want to reply, show the command only when they ask:

gh pr comment <N> --body "<reply>"    # PR-level reply
# inline thread reply:
# gh api repos/<owner>/<repo>/pulls/<N>/comments/<comment_id>/replies -f body="<reply>"