Evaluate Code Review 是一个面向“处理别人给出的代码审查反馈”的技能。它的定位是分诊（triage），不是自己写审查。反馈来源可以是人工审查者、一个或多个 AI 机器人（Copilot、CodeRabbit、Devin、Bito、Greptile）、此前自己的审查，或一份 Markdown 审计文档。
用途与触发场景：当用户在整理 GitHub PR 上收到的评论（例如“评估这次审查”“处理 PR #42 的评论”“机器人对我的 PR 说了什么”）、合并同一 PR 上多个审查者的反馈（例如“Copilot 和 CodeRabbit 意见不一致”“把三位审查者的意见合并”“把机器人评论聚类”）、审计当前对话中较早的审查反馈、把 Markdown 审查/审计文档转成行动计划，或面对没有明确来源的“看一下这个审查”这类模糊提示时使用。不适用场景包括：自己执行审查（应使用 do-review）、为 PR 请求反馈（作者侧，应使用 ask-review）、在没有任何审查反馈的情况下核对“已完成 vs 声称已完成、”以及运行 orchestrate-codex 的逐分支收敛循环。
不可协商的规则：一是实施前先验证，每条建议都要对照实际代码确认，因为人工与机器人审查者都可能出错、过时或缺少上下文；二是禁止表演式同意，不写感谢、赞美、道歉或未经验证的赞同，代码 diff 本身就是回应；三是在读反馈前先重建真实改动；四是始终派发一个 Explore 子代理做独立分析，且提示词自包含、不泄露会话历史；五是当有 2 个及以上审查者提到同一文件与行时，先聚类再评估；六是实施时一次只处理一项，修一项、测一项；七是实施顺序为阻塞性问题→简单问题→复杂问题；八是当审查者确实有误时用技术理由反驳；九是证据优先于来源权威。
来源置信度模型：人工审查者通常携带产品、上线与架构上下文，但行内评论可能基于较旧提交而过时；AI 机器人覆盖广、模式匹配一致，但严重性标签只是提示；自我审查或 Markdown 文档提供有用的事前分析，但常缺少当前代码状态。所有来源使用同一套正确性标准；来源类型只影响解析方式、分诊优先级与回复渠道。当代码证据相等时，人工的产品/架构上下文可作为决胜依据；机器人反复一致可提升优先级，但不能决定对错。
输入模式：PR 模式（如“PR #42 的审查评论”“机器人对我的 PR 说了什么”“处理审查”）、会话审计模式（如“审计我们刚做的事”“检查之前的审查笔记”）、Markdown 文档模式（如“读 review.md 给我一个行动计划”“审查者笔记在 audit.md 里”）。若触发词模糊，则先扫描此前消息，再对当前分支执行 gh pr view，最后在工作目录查找 review*.md、audit*.md、feedback*.md，并在继续前报告找到的内容。
必需工作流：第 1 步识别输入模式并呈现反馈，把所有反馈抽成扁平条目，逐字记录原文以及来源、位置、代码范围等元数据，PR 模式需先运行 scripts/parse-pr-comments.sh 抓取三类 GitHub 反馈渠道。第 2 步重建真实改动集，回退链为：分支领先于 base 的提交（git log / git diff）→ 会话中的 Edit/Write 调用 → 会话中的 Bash rm/mv/mkdir/cp 调用 → 以上都没有则声明真实情况不确定。第 3 步始终派发 Explore 子代理，提示词自包含，交付真实改动集、反馈条目列表和验证镜头指引，子代理逐条返回 verdict（correct/incorrect/unverifiable）、evidence 与 severity。第 4 步在多来源时合并反馈：按行范围聚类（±5 行为典型模糊区间）、去重、显式暴露冲突、把明显误报标记为“有理由驳回”，PR JSONL 快照可先运行 scripts/cluster-feedback.py。第 5 步逐条（或逐簇）对照代码库评估，结论为 ACCEPT、PUSHBACK、CLARIFY、DEFER 或 DISMISS；验证镜头包含六个检查：正确性、范围（YAGNI，先 grep）、技术栈契合、兼容性、上下文、架构一致性。第 6 步产出行动计划，PR 模式在获授权后通过 gh api 在线程内回复（仅总结用顶层），会话审计模式输出 Markdown 行动计划，Markdown 文档模式把计划写在源文档旁；每种计划都带决策登记表，包含稳定条目 ID、来源、来源类型、位置与 commit_id、审查者原文、结论、证据、拟采取动作与实施状态。第 7 步仅在获授权时实施被接受的条目：破坏性或对外可见的动作（推 PR、发评论、部署、删除）每次都要显式授权；顺序为阻塞→简单→复杂；一次一项、逐项测试；完成后汇报已修条目 ID、改动文件、提交 SHA、验证命令与确切结果、剩余条目以及 PR 回复状态。
语气纪律：不写感谢、赞美、道歉或未经验证的同意；接受正确反馈时直接说明修复内容（如“Fixed. <改了什么>”），有异议时用证据反驳，只有在证据确实不足时才请求澄清。
多机器人 PR 常用命令：gh pr view <N> --repo <o>/<r> --json reviews 拉取顶层审查；gh api repos/<o>/<r>/pulls/<N>/comments 拉取行内评论；gh api repos/<o>/<r>/issues/<N>/comments 拉取 PR 讨论评论；线程内回复用 gh api repos/<o>/<r>/pulls/<N>/comments/<id>/replies --method POST --field body="Fixed. <description>."。
输出契约：按顺序产出输入模式声明、真实改动摘要（注明用了哪条回退链）、子代理派发报告、合并表（仅多来源）、决策登记表、行动计划、实施报告。
参考文件路由：references/voice.md（措辞禁令与反驳模板）、references/rationalizations.md（绕过“先验证再实施”的借口与反驳）、references/understand-changes.md（重建改动集）、references/subagent-dispatch.md（子代理提示模板）、references/verification.md（6 项验证镜头）、references/multi-agent-consolidation.md（多审查者聚类与冲突解决）、references/gh-review-workflow.md（gh 拉取与回复渠道）、references/action-plan-output.md（各模式计划格式）、scripts/parse-pr-comments.md 与 scripts/cluster-feedback.md。
护栏与恢复：不得写感谢/赞美/道歉或未验证的同意（出现即删除）、不得未验证就实施、不得让子代理提示引用“此前对话”、不得在两位审查者冲突时静默选边、不得无理由驳回机器人反馈、不得为省时间在反驳上让步。无法验证某建议时说明限制并询问；与既有架构决策冲突时停下并向人工提出；反驳后发现自己错了则直接纠正。所有具体命令、脚本和参考文件名均以上述资料为准，未提供的收费、平台支持范围等信息暂未提供。