当 PR 存在未解决的评审评论时，逐条判断并修复、回复…

在 GitHub PR 有未解决的行内评审评论时，逐条评估、修复、提交、回复并解决线程。

适用场景

解决思路

1. 按固定阶段顺序执行：fetch → analyze → fix → validate → push → reply → resolve → verify，除非用户明确要求不同顺序；不要把 GitHub 线程变更与代码编辑重试交错进行。
2. 先判断分支/worktree 上下文：检查当前检出分支是否等于 PR 的 head 分支；若相同则直接在该分支继续，不要询问 worktree；若不同或处于 main/master 等共享长期分支，则先询问是否使用专用 git worktree，若同意则创建/使用该 worktree 并在其中继续。
3. 收集未解决评论并建立工作跟踪表：若提供了带 #pullrequestreview-<id> 的评审 URL，先解析出 owner、repo、PR number、review id；复制或打开 assets/review-resolution-checklist.md 作为工作文档，填写上下文并持续更新评论跟踪表；拉取 PR 的评审线程并过滤出未解决线程；若指定了 review id 或评审 URL，则只限定该评审的评论；在该评审内收集所有关联该 review id 的评论（除非明确要求，不包含其他评审的回复）；构建工作列表，包含 thread id、comment id、parent review id、文件路径、原始评论正文以及该线程内所有后续回复（含贡献者回复）；完整阅读每个线程的回复链，因为贡献者可能补充了澄清、约束或额外上下文；在任何 GitHub 变更前记录目标 thread id 基线列表和未解决线程数。
4. 逐条理解、调研并判断评论：阅读被引用的文件和附近逻辑；结合当前代码、需求和上下文判断反馈是正确、部分正确、过时还是错误；评审者不一定正确，不要为了满足过时或错误的评论而制造无谓的代码改动；若反馈正确，验证根因并找出最小安全修复；若反馈明显错误或过时，准备简洁的、基于证据的回复而不是不必要地改代码；若不确定，先检查相邻测试/用法再编辑；若本地调研后仍有疑问，在改代码或变更该评审线程前先询问用户。
5. 逐条修复、检查、提交：仅对判断为有效或部分有效的评论应用聚焦的代码/文档改动；先运行针对性检查，再运行仓库要求的检查；在可行时每条评论一个提交；若两条评论需要同一个不可分割的改动，则用一个提交并在回复中把两条评论都映射到该提交；对拒绝的评论，在跟踪表中记录理由，以便最终回复明确且可审计。
6. 所有修复完成后只推送一次：在所有与评论相关的提交创建完成后，推送一次分支更新。
7. 逐条回复并解决评审评论：在任何线程变更前，按以下顺序优先使用结构化工具：1) 当前客户端会话中暴露的专用 GitHub MCP 评审线程回复/解决工具，2) 捆绑的 GraphQL 资产或捆绑的 scripts/resolve-review-comments.sh，3) 绝不使用临时 Python 脚本、一次性批处理助手或盲目 gh api 重试循环；在发布任何内容前，从清单/跟踪表为每个目标线程准备恰好一条计划回复；若回复/解决尝试报错、超时或返回不确定结果，重试前重新拉取当前线程状态；对每个线程，以下两步是强制的且必须按顺序一起发生，除非该线程仍不确定并在等待用户输入：1) 在线程上发布回复：要么描述改了什么并包含提交哈希，要么解释为何未改代码因为评论错误/过时；2) 回复发布后立即解决该线程——绝不提前；每次运行每个线程最多尝试发布一条回复；若已存在等价的 agent 撰写的回复，不要再发一条，复用它并仅在线程仍未解决时解决；若已存在不同的 agent 撰写的回复，停止并手动检查，而不是再堆叠一条评论；不要解决仍不确定的线程，先升级给用户；绝不在没有回复的情况下解决线程；绝不在发布回复后不解决线程；回复要具体：写明改动的文件/行和提交，而不只是“fixed”。
8. 验证关闭状态：重新检查评审线程，确认没有目标未解决线程残留；确认目标未解决线程数降为零，且本次运行未创建重复的 agent 回复；若工作流要求绿色检查，重新检查最新 CI 状态。
9. 询问是否向原评审作者请求新评审：在修复已推送且线程已解决后，询问用户是否想向评审评论的作者请求新评审；若同意，向该评审者用户名请求评审并报告请求已发送。
10. 可选脚本化执行：使用 scripts/get-review-comments.sh 拉取匹配的评审评论（含与 review id 关联的子评论）；结果限制为前 100 个评审线程和每线程前 100 条评论；示例测试：skills/.experimental/fusion-github-review-resolution/scripts/get-review-comments.sh --owner equinor --repo fusion-skills --pr 27 --review-id 3837647674；需要过时匹配线程的评论时使用 --include-outdated；使用 scripts/resolve-review-comments.sh 回复并解决匹配线程，带 dry-run 优先的重复回复保护；保持默认 dry-run 行为，仅在修复已提交并推送后使用 --apply；默认情况下脚本拒绝向已包含一条认证用户回复的线程再添加回复，仅在手动检查后使用 --allow-additional-reply；示例 dry-run：skills/.experimental/fusion-github-review-resolution/scripts/resolve-review-comments.sh --owner equinor --repo fusion-skills --pr 27 --review-id 3837647674 --include-resolved；示例 apply：skills/.experimental/fusion-github-review-resolution/scripts/resolve-review-comments.sh --owner equinor --repo fusion-skills --pr 27 --review-id 3837647674 --apply --message "Addressed in <commit>: <what changed>."。
11. 工具选择：高层 PR 操作和当前客户端暴露的专用评审线程变更使用 GitHub MCP 工具；当 MCP 覆盖缺失时，线程级评审操作使用 GraphQL；请求评审者/更新 PR 元数据用 mcp_github_update_pull_request；创建或提交 PR 评审用 mcp_github_pull_request_review_write；添加一般 PR 评论用 mcp_github_add_issue_comment（这是 issue 风格评论，不是行内线程回复）；列出评审线程和评论用 assets/pull-request-review-threads.graphql，配合 gh api graphql -f query=@assets/pull-request-review-threads.graphql 获取线程级上下文；统计特定 review id 的未解决线程数用 assets/unresolved-thread-count-for-review.graphql，并对响应后处理（例如用 jq）按 review id 和未解决状态过滤；回复评审线程优先用专用 MCP 评审线程回复工具，否则用 assets/add-pull-request-review-thread-reply.graphql；解决评审线程优先用专用 MCP 评审线程解决工具，否则用 assets/resolve-review-thread.graphql；注意 GraphQL 中 resolveReviewThread 使用 threadId，而不是 pullRequestReviewThreadId；列出 PR 评审（支持评审 URL/id 查找）用 assets/pull-request-reviews.graphql。
12. GraphQL 成本意识：评审解决工作流会进行多次 GraphQL mutation 调用（每线程 reply + resolve），要保守；每个 mutation 花费 5 个 secondary-limit 点（读查询为 1），处理多线程时据此预算；连续 mutation 调用之间至少暂停 1 秒以避免 secondary 速率限制；保持 first/last 连接参数较小（仅在需要单页获取所有线程时才用 first: 100）；若返回 secondary 速率限制错误或 retry-after 头，停止处理并遵守指示的等待时间后再重试；当客户端暴露专用 MCP 评审线程工具时，始终优先于原始 GraphQL。
13. Token 预算指导：一次性拉取完整线程列表并在所有逐线程工作中复用，不要在 reply 和 resolve 之间重新拉取线程；预算估算：N 个未解决线程约需 1 次列表调用 + N 次 reply mutation + N 次 resolve mutation = 1 + 2N 次调用，10 线程评审约 21 次调用；若线程数超过 15，在开始 mutation 前警告用户速率限制风险，并提出分批处理；从首次拉取缓存 PR 元数据（标题、分支、CI 状态、变更文件），用于提交信息和回复；避免步骤间冗余的 PR 级读取，数据在单次解决运行内不会变化。
14. 返回简洁报告，包含：处理的评论数、处置摘要（已修复、已拒绝并附理由、已升级给用户）、变更的文件、提交列表（哈希 + 信息）、运行的验证命令及结果、推送确认、每线程的回复/解决确认、完成的清单位置、任何剩余未解决线程或阻塞项。
15. 当提供了 issue（例如 equinor/fusion-core-tasks#432）：在进度/最终摘要中提及该 issue；保持实现与 issue 范围一致；避免扩展到无关的 PR 自动化。
16. 安全与约束：此技能具备变更能力，仓库本地工作流说明在冲突时优先于内联指导；绝不在日志/回复中暴露密钥或令牌；优先使用基于 argv 的进程执行而非 shell 插值命令字符串；保持 diff 最小并限定在评审反馈范围内；不要假设评审反馈正确，先结合代码和需求推理；若评论在调研后仍含糊，询问用户而不是猜测；不要在没有发布具体修复回复的情况下解决线程；除非命令实际运行过，不要声称检查通过；不要 force-push，使用常规提交并在所有修复后单次推送；若评论过时但仍未解决，要么用清晰解释和提交引用解决，要么保持未解决并报告原因；在脚本模式下，保持默认 dry-run 行为，变更需要显式 --apply。

适用边界 · 注意事项

• 没有未解决的评审评论时
• 请求只是总结或描述反馈而不做代码改动时
• 所有目标线程已解决或已过时并已确认，或分支/worktree 有意为只读时