用途：系统化处理 GitHub PR 上的评审评论线程。由于评审线程的已解决状态只存在于 GraphQL，REST API 无法读取 isResolved 或解决线程，gh pr view --comments 也只显示 issue 评论而隐藏行内评审线程，因此该技能通过 scripts/gh-pr-comments.ts 走 GraphQL，使用 gh auth token 认证。
主要能力与流程：拉取未解决线程；在动手前逐条核实评论所指代码（机器人评审常对也常自信地错）；只修复真实问题，且提交与原始工作分开，便于评审者看到改动；对每条线程回复，包括拒绝的；解决每条线程；确认无遗留后最后推送。推送必须放最后，否则线程在修复推送前被解决会显得像被驳回。
命令：SKILL="${CLAUDE_PLUGIN_ROOT}/skills/tackle-gh-comments/scripts/gh-pr-comments.ts"；bun $SKILL list 列出当前 PR 未解决线程；bun $SKILL list --pr 1044 --all 指定 PR 并含已解决；bun $SKILL json 输出机器可读结果；bun $SKILL handle --thread <id> --body "..." 回复并解决；bun $SKILL reply 仅回复；bun $SKILL resolve 仅解决；bun $SKILL verify 若有未解决线程则退出码 1。仓库与 PR 号从当前检出推断，可用 --repo owner/name 和 --pr N 覆盖；线程 id 为不透明 GraphQL 节点 id，需原样传回。多行回复用 heredoc 以保留反引号和引号。
核实要点：不要仅凭评审者说法就改。对“违反约定 X”要查约定原文及邻近代码是否也违反；对“引用过时/会坏”要 grep 确认目标确实消失并排查遗漏；对“这是 bug”要构造失败输入，构造不出就在回复中说明而非臆测修改；行为保持型修复要给出前后输出 diff 或运行覆盖测试并说明。若修复是新增强制规则，需先对真实使用方核实规则、注入失败证明检查会触发、确认检查确实运行。
回复写法：说明发生了什么、附 commit sha 和足够推理。已修复写明 sha、改动与验证方式；以不同方式修复说明替代方案及原因；拒绝给出技术理由并视情况提供后续；部分修复明确未做部分及原因。不要用感谢评审的填充语。
陷阱：修复推送前就解决线程；gh pr view --comments 看似为空；机器人每次推送后重审可能开新线程，推送稳定后需重跑 list；outdated 线程仍应回复；为让 PR 变绿而一律解决。完成标准：bun $SKILL verify 退出 0，每条线程都有实质回复，修复已提交且分支已推送。