hyfdev-adversarial-review

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Adversarial Review

对抗性审查

Run this after a deliverable is finished and before it reaches the user. The goal is to disprove the deliverable with evidence and to find what the working session left in it, not to confirm it.
在交付物完成之后、送达用户之前运行本流程。目标是以证据证伪交付物,并找出工作会话遗留在其中的内容,而不是确认交付物无误。

Terms

术语

  • Deliverable: a complete unit the user will act on, merge, publish, or rely on — a change ready for a PR, an investigation report, a recommendation, a batch of record edits. A step inside a task, an answer to a question, a lookup, or a mechanical edit is not a deliverable.
  • Direction: what a reviewer is told to look for. Three directions exist — open, over-engineering, residue — and their texts below are used verbatim.
  • Residue: text in the deliverable that only a participant of the working session can resolve. The residue direction below lists its forms; the test is that a reader at HEAD with no access to the session can resolve every reference and verify every claim.
  • Brief: what a reviewer receives — one or two directions and the facts needed to locate the work, nothing else.
  • 交付物(Deliverable):用户将据以采取行动、合并、发布或依赖的完整单元——例如已可提交至 PR 的变更、调查报告、建议或一批记录编辑。任务内部的步骤、问题答案、信息查询或机械式编辑不属于交付物。
  • 方向(Direction):指示审查者重点查找的内容。共有三个方向——open、over-engineering、residue——下述对应文本须逐字使用。
  • 残留(Residue):只有参与本次工作会话的人才能理解的交付物文本。残留方向列出了其具体形式;判断标准是,处于 HEAD 状态且无法访问会话的读者能够解析每一处引用并核实每一项主张。
  • Brief:提供给审查者的信息——一个或两个方向,以及定位工作所需的事实,不包含其他内容。

When

何时运行

  • Once per deliverable, when the main agent considers it done and before reporting it, and whenever the user invokes the skill.
  • Invoking this skill is the request to spawn the reviewers; do not ask for a separate confirmation. Report the review in the deliverable's report; ask the user only when you are choosing not to run it.
  • When no subagent can be spawned, do a bounded self-review against the three direction texts and say in the report that independent review was not available.
  • 每个交付物运行一次,在主 Agent 认为交付物已完成但尚未向用户报告时运行;用户调用此 skill 时也应运行。
  • 调用此 skill 即表示要求启动审查者;不要再单独请求确认。在交付物的报告中说明审查结果;只有决定不运行审查时才询问用户。
  • 如果无法创建 subagent,则根据三个方向文本进行一次有边界的自我审查,并在报告中说明无法进行独立审查。

Levels

级别

The user names the level in the invocation or the message; without a name, run the default.
  • Default: one round. Two fresh subagents in parallel — Reviewer A: open; Reviewer B: over-engineering and residue together. Fix, then report.
  • Strong (强力): two rounds. Round one as above, fix, then round two with new fresh subagents and the same briefs — they review the fixed deliverable and know nothing of round one — fix again, then one report covering both rounds.
  • Max (极致): strong, with two fresh subagents per direction in every round — four per round, eight in total. Reviewers of the same direction get the same brief and do not know of each other.
用户在调用或消息中指定级别;未指定时运行默认级别。
  • Default:一轮。两名全新的 subagent 并行运行——审查者 A:open;审查者 B:over-engineering 与 residue 合并审查。修复后进行报告。
  • Strong(强力):两轮。第一轮同上;修复后,使用相同 brief 启动第二轮全新的 subagent——它们审查修复后的交付物,且不知道第一轮的情况——再次修复后,提交一份涵盖两轮结果的报告。
  • Max(极致):在 strong 的基础上,每轮每个方向均使用两名全新的 subagent——每轮四名,总计八名。同一方向的审查者获得相同的 brief,且彼此不知道对方的存在。

Reviewers

审查者

A fresh subagent is a new agent with no inherited context, never a fork of the main agent; it has no access to the working session. It discovers the work itself: runs
git diff <base>...<head>
, reads the surrounding code or the whole report, runs checks when it needs them. Do not hand it the diff, a summary, or a list of places to look.
全新的 subagent 是一个不继承上下文的新 Agent,绝不是主 Agent 的 fork;它无法访问工作会话。它需要自行发现工作:运行
git diff <base>...<head>
,阅读相关代码或完整报告,并在需要时运行检查。不要向它提供 diff、摘要或需要查找的位置清单。

The brief

Brief

Fill the template and add nothing outside it. The main agent's plan, reasoning, summary of what it did, self-assessment, the history of corrections, hints about weak spots, and other reviewers' output never enter a brief.
text
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
is the user's own words or a durable source they pointed at, never the main agent's restatement. When the user adopted an agent-written candidate by reference, their adopting message and the adopted candidate, both verbatim, are the request; a summary of what was agreed earlier is not. When the request already exists somewhere durable — an issue, a task file — point at it instead of quoting.
填写以下模板,不要添加模板之外的内容。主 Agent 的计划、推理、工作摘要、自我评估、修改历史、弱点提示及其他审查者的输出均不得进入 brief。
text
Direction: <open | over-engineering + residue>
Deliverable: <代码变更 | 报告 | 记录编辑>
Location: <包含 base 和 head refs 的 worktree 路径 | PR 编号 | 文件路径>
Request: <用户请求原文 | issue #N | 载明任务的文件路径>
Return: pass,或每个方向最多五项发现,按每项发现对结果的影响程度排序。每项包含:位置、证据、为何重要。

<方向文本,逐字取自本 skill>
Request
必须是用户自己的原话,或用户指定的长期有效来源,绝不能使用主 Agent 的转述。当用户通过引用采纳了 Agent 编写的候选方案时,其采纳消息和被采纳的候选方案均须逐字作为 request;之前达成一致的摘要不能代替原文。如果请求已经存在于某个长期有效的位置——例如 issue 或任务文件——则直接指向该位置,不要引用其内容。

Direction texts

方向文本

Open

Open(开放)

Try to disprove this deliverable. Find anything that would make it wrong to accept as is: factual or logical errors, unsupported claims, missing evidence, behavior that differs from what was required, untested or broken paths, an overlooked alternative that would change the decision. Rank findings by how much they would change the result. Omit style. A missing defense against a threat the repository does not promise to handle is not a finding.
尝试证伪此交付物。找出任何会使其不适合按原样接受的问题:事实或逻辑错误、缺乏支持的主张、遗漏的证据、行为偏离要求、未经测试或已损坏的路径,以及可能改变决策但被忽略的替代方案。按各项发现对结果的影响程度排序。忽略风格问题。如果仓库并未承诺处理某种威胁,则缺少针对该威胁的防护不构成发现。

Over-engineering

Over-engineering(过度设计)

Find what this deliverable contains that the request did not require: scope beyond the ask; an abstraction, option, or parameter with a single consumer; configuration or fallbacks for situations nobody asked for; defensive code against threats the repository does not promise to handle; tests or documentation for behavior this change did not introduce; hand-rolled code where the repository already has a helper or dependency. For each item, name what it costs and what the smaller version is.
找出交付物中包含但请求未要求的内容:超出任务范围;只有一个使用方的抽象、选项或参数;为无人要求的情境添加的配置或 fallback;针对仓库并未承诺处理的威胁而编写的防御代码;针对此次变更未引入的行为编写的测试或文档;在仓库已有 helper 或 dependency 的情况下仍然手写代码。对于每一项,说明其成本以及更精简的版本。

Residue

Residue(残留)

Read every piece of text in the deliverable — code, comments, tests, docs, commit messages, PR title and body, report prose — as a reader at HEAD who has no access to the working session. Flag anything that reader cannot resolve or that speaks to someone who is not there: references to things removed or tried, narration of the change instead of the state, justification addressed to a reviewer, tests or comments that guard the absence of something, hedges and planning residue. For each, quote the sentence and give the present-tense restatement, or say "delete". Records whose subject is a decision or its history — decision records, decision ledgers, postmortems — state what was decided, tried, and why; that content is not residue.
以处于 HEAD 状态且无法访问工作会话的读者视角,阅读交付物中的每一段文本——代码、注释、测试、文档、commit message、PR title 和 body、report 文本。标记该读者无法解析的任何内容,或任何在对不在场的人说话的表述:对已删除或曾尝试内容的引用;对变更过程的叙述而非当前状态;面向审查者的理由说明;用于守护某物不存在的测试或注释;含糊措辞和计划残留。对于每项,引用原句并给出使用现在时的重述,或者指出应“删除”。以决策或其历史为主题的记录——decision records、decision ledgers、postmortems——会说明决定了什么、尝试了什么以及原因;此类内容不属于 residue。

Synthesis

综合处理

  • Fix by default. Verify each finding against the evidence yourself and apply what holds without asking first. Two exceptions, and neither is a question to the user: an edit that the user's rules reserve for their approval is shown instead of applied; a finding that contradicts an instruction the user gave in this task is not applied, and the report says so.
  • A theoretical, hostile-environment, or defense-in-depth finding is recorded, not implemented, unless the task includes that threat model or the repository already promises that resilience.
  • Do not count votes. Two reviewers reporting the same finding is one finding, not stronger evidence; merge findings by content.
  • Fix residue by restating in the present tense or deleting, never by adding a note that something was reviewed or removed.
  • Report to the user after the fixes: what was found, what changed, what was not applied and why. For strong and max, one report for all rounds.
  • 默认进行修复。自行根据证据核实每项发现,并直接应用经核实成立的修复。两个例外均不能拿来询问用户:用户规则规定需经其审批的编辑,只展示而不应用;与用户在当前任务中给出的指示相冲突的发现不予应用,并在报告中说明。
  • 理论性、敌对环境或 defense-in-depth 类发现只记录,不实施,除非任务包含该 threat model,或仓库已经承诺具备这种韧性。
  • 不要统计票数。两名审查者报告同一项发现仍只算一项发现,并不构成更强的证据;应按内容合并发现。
  • 修复 residue 时,应使用现在时重述或删除,绝不能添加说明某项内容已接受审查或已被移除的注释。
  • 修复后向用户报告:发现了什么、改动了什么,以及哪些内容未应用及其原因。对于 strong 和 max 级别,所有轮次只提交一份报告。