用途：该技能说明如何把 pull request 推进到可合并状态，核心是两件事——每个评审问题都有答复，每个把关检查都真正运行过，不能只看摘要。
评审对话：合并前必须解决每个评审线程，包括不认同的和已过时的。解决不等于同意，回复需说明三种结果之一：已修复（给出提交及现在约束它的符号）、不修复（具体说明成本、范围或更高优先级规则，不能只写“有意如此”）、已过时（说明为何不再适用）。静默解决要避免，因为它与真正修复看起来一样。PR 页面摘要和 gh pr view 不列出未解决线程，需用 GraphQL API 查询：gh api graphql -f query='{ repository(owner:"OWNER", name:"REPO") { pullRequest(number:NN) { reviewThreads(last:60) { nodes { id isResolved isOutdated path comments(last:1){nodes{author{login} body}} } } } } }' --jq '.data.repository.pullRequest.reviewThreads.nodes[] | select(.isResolved==false) | "(.path) | (.comments.nodes[0].body[0:160])"'。回复与解决分别用 addPullRequestReviewThreadReply 和 resolveReviewThread 两个 mutation。机器人评审（如 Copilot）也算数，分支变动后其发现可能过时，仍需一行回复说明。
检查运行：gh pr checks 只显示连接到 PR 的检查，常是子集，应按提交 SHA 枚举工作流：gh run list --branch BRANCH --limit 20 --json name,headSha,status,conclusion --jq '.[] | select(.headSha|startswith("SHA")) | "(.name) | (.status) | (.conclusion)"'。合并前还需确认运行在头提交而非旧提交（推送会取消进行中的运行），以及 CI 构建的是否为合并结果：git merge-base --is-ancestor origin/main HEAD——true 表示为快进、结果完全适用；false 表示合并产生的树未被构建，需先更新分支。合并后也要检查 main。
审批与风格：没有明确审批不得合并，且每次合并都需负责人逐次批准；若批准是“你觉得安全就合”的判断性授权，则需完成上述尽职调查并说明检查了什么。合并风格按仓库已有习惯，读取基础分支的 git log --oneline 判断是压缩还是保留合并提交。
PR 撰写：公开内容只写事实——问题、改动、结果、测试，不写内部计划、工单路径、项目名、角色名、智能体或模型名及内部讨论，提交与 PR 正文不加 AI 署名。描述应说明原来哪里有问题、现在靠什么防止，而非仅说改了什么。评审轮次发现缺陷后，把解决情况作为评论发布：哪些确认、哪些驳回及原因、验证了什么。
限制：资料未提供该技能的执行环境、依赖安装、适用仓库类型、费用与可用平台等信息，暂未提供；使用时需将命令中的 OWNER、REPO、NN、BRANCH、SHA 等占位符替换为实际值。