hyfdev-adversarial-review

对抗性审查

在交付成果完成后、交给用户之前运行此流程。目标是用证据推翻交付成果，并找出工作过程中遗留其中的问题，而不是证实它。

术语

• 交付成果：用户将采取行动、合并、发布或依赖的完整工作单元，例如准备好提交 PR 的更改、调查报告、建议或一批记录编辑。任务中的一个步骤、对问题的回答、一次查询或机械性编辑都不算交付成果。
• 审查方向：告知审查者应查找什么。共有三个方向——开放式、过度工程和残留问题；下文给出的文本须原样使用。
• 残留问题：交付成果中的文本，只有参与工作过程的人才能理解。下文的残留问题方向列出了它的形式；判断标准是：读者在 HEAD 版本中，且无法访问工作过程时，能否解析每处引用并核实每项主张。
• 审查简报：审查者收到的内容——一个或两个审查方向，以及定位工作所需的信息，不包含其他内容。

何时运行

• 每个交付成果运行一次：主 Agent 认为工作已完成、但尚未报告时；以及用户每次调用此技能时。
• 调用此技能即表示要求启动审查者；不要另行请求确认。在交付成果的报告中说明审查结果；只有在决定不运行审查时才询问用户。
• 如果无法启动子 Agent，则根据三个审查方向的原文进行有限的自我审查，并在报告中说明无法进行独立审查。

级别

用户会在调用或消息中指定级别；如果未指定，则运行默认级别。

• 默认：一轮。并行启动两个全新的子 Agent——审查者 A：开放式；审查者 B：同时审查过度工程和残留问题。修复后报告。
• 强力：两轮。第一轮按上述方式进行，修复后，第二轮由新的子 Agent 使用相同简报进行审查；他们审查修复后的交付成果，且不了解第一轮情况。再次修复后，提交一份涵盖两轮的报告。
• 极致：强力模式，每轮每个方向启动两个全新的子 Agent——每轮四个，总共八个。同一方向的审查者收到相同简报，彼此互不知情。

审查者

全新的子 Agent 是指没有继承上下文的新 Agent，绝不是主 Agent 的分支；它无法访问工作过程。它会自行查找工作：运行 git diff <base>...<head>，阅读相关代码或完整报告，并在需要时运行检查。不要向它提供 diff、摘要或需要查看的位置列表。

审查简报

填写模板，除此之外不添加任何内容。主 Agent 的计划、推理、工作摘要、自我评估、修改历史、对薄弱之处的提示，以及其他审查者的输出，都不得出现在简报中。

Direction: <open | over-engineering + residue>
Deliverable: <code change | report | record edits>
Location: <worktree path with base and head refs | PR number | file paths>
Request: <the user's request, verbatim | issue #N | path to the file that states the task>
Return: pass, or at most five findings per direction, ranked by how much each would change the result. For each: location, evidence, why it matters.

<direction text, verbatim from this skill>

Request 是用户自己的原话，或用户指定的持久来源，绝不能是主 Agent 的转述。当用户通过引用采纳 Agent 撰写的候选内容时，用户采纳该内容的消息和被采纳的候选内容都必须原样作为请求；不能用对先前协商内容的摘要代替。如果请求已经存在于某个持久位置——例如 issue 或任务文件——则指向该位置，而不是引用其内容。

审查方向文本

开放式

尝试推翻此交付成果。找出任何足以说明不应原样接受它的问题：事实或逻辑错误、缺乏依据的主张、证据缺失、与要求不符的行为、未经测试或已损坏的路径，以及可能改变决策却被忽视的替代方案。按其对结果的影响程度排列发现。忽略纯粹的外观偏好。如果在保留目标读者所需理解或决策信息的前提下，可以用更简单的措辞表达，则指出可避免的重复或复杂性。仓库并未承诺要处理的威胁，缺少针对它的防护不算问题。

过度设计

找出这项交付中请求未要求的内容：超出要求的范围；只有一个使用方的抽象、选项或参数；没人要求处理的情况所需的配置或回退方案；针对仓库并未承诺处理的威胁编写的防御性代码；用于说明本次更改未引入行为的测试或文档；仓库已有辅助函数或依赖，却仍手写实现的代码。对于文字内容，准确且相关并不代表必不可少：检查是否重复解释或举例，以及是否包含不会影响读者理解或决策的细节。对每一项，说明其代价和更精简的做法；对于文字内容，引用要删除或精简的原文，并给出删除或替换方案，同时保留解释正确性、范围和权衡所必需的内容。

遗留内容

以一个无法访问工作会话、正在查看 HEAD 的读者身份，阅读交付中的每一处文字——代码、注释、测试、文档、提交信息、PR 标题和正文、报告文字——标出读者无法理解的内容，或写给不在场之人的内容：提及已删除或尝试过的事项、叙述更改过程而非当前状态、面向审查者的辩解、用于确保某项内容不存在的测试或注释、犹豫不决或规划过程的残留。对于每一项，引用原句并改写成现在时的表述，或注明“删除”。主题是决策及其历史的记录——决策记录、决策日志、事后分析——应说明作出了什么决定、尝试过什么以及原因；这类内容不属于遗留内容。

综合处理

• 默认直接修复。根据证据逐项核实发现，并直接落实成立的修改，无需先询问。以下两种情况除外，而且都不需要询问用户：用户规则要求其批准的修改，应展示而不直接应用；与用户在本任务中给出的指令相冲突的发现，不予应用，并在报告中说明。
• 理论上的、针对恶意环境的或纵深防御方面的发现，应记录而不实施，除非任务包含相应威胁模型，或仓库已承诺提供此类韧性。
• 不要按票数裁定。同一发现被两位审查者提出，仍只算一项，不代表证据更充分；按内容合并发现。
• 修复遗留内容时，应改写为现在时或直接删除，绝不添加说明某项内容已审查或已删除的注记。
• 修复后向用户报告：发现了什么、改动了什么、哪些内容未予应用以及原因。对于 strong 和 max，各轮只提交一份报告。