review-pr

以高信噪比自主审查 PR，并以你的账号发布。只提交你愿意署名的审查意见——精准优先于覆盖面。

输入。 从参数或当前分支的上游 PR 获取 pr-url。--manifest <path> 会将技能切换到清单模式：跳过通用审查器团队，只验证清单中的契约——而非仅依据作者意图来约束审查器团队。仅在该模式下，才加载 references/MANIFEST_MODE.md 获取验证机制；未使用 --manifest 时，绝不读取该参考文件，并运行通用 review-code 团队。技能不会根据任何文件夹约定自动发现清单。--bundle <urls> 加上对 PR 描述中关联 PR 的解析（Depends on #N、Stack:、Co-changes:、GitHub PR URL），可为存在依赖关系的更改提供跨 PR 上下文。决定如何处理之前，先解析 PR、当前 head SHA、我们此前发布的 GitHub 审查/评论/回复、未解决的审查线程、作者的提交、PR 描述以及关联 PR 的上下文。

审查组织。 在本会话中执行所需检查，或在有用时委派给独立上下文；相关工作可以共用一个上下文。其他上下文可协助进行独立判断、可分离的工作或大量阅读。如果不具备此能力，则在当前上下文中完成。工作安排不会改变对每个线程、维度和关卡的必要覆盖范围、技能标准或结果。遵循明确提出的独立审查要求，并如实报告实际使用的上下文，不得在并不存在独立审查时声称审查独立于作者。

自动标记。 以你自己的账号发布，意味着人工审查者也会使用同一账号，因此仅凭作者身份无法区分我们的自动评论和人工评论。此技能发布的每条正文——新的问题评论、线程回复、摘要标题、批准正文以及清单模式下的 PASS/FAIL——都必须加上尾随的隐藏标记 ，这是固定的字面字符串，无论此技能以何种名称运行都必须逐字节一致；否则，从一台主机发布的评论将无法与另一台主机发布的评论匹配。GitHub 会在渲染后的评论中移除该标记，但会通过 API 返回它。正是这个标记，而非账号作者身份，决定评论是否属于自动化的 review-pr 评论：此技能中所有提及*我们撰写或回复的线程/评论*（或*我们此前的*审查/评论）之处，均指带有该标记的内容；因此，我们账号上没有标记的评论应视为人工评论，不予改动。清单模式会在标记中加入标准 ID（`references/MANIFEST_MODE.md`）。判断阶段的审查问题会在标记中加入 `judgment` 标记——，以便在两种模式下将此前的判断类问题与普通 review-pr 评论区分开来（继续审查时会利用此标记恢复此前的判断结果，避免重复提出）。

单次检查

每次调用都会完整推进一次 PR 状态，包括不带 --loop 的调用：

1. 推进现有讨论串。 对 逐讨论串验证 覆盖的每个讨论串，执行验证并按其结论采取行动。发布所需的讨论串回复，解决已终结的讨论串，重新打开问题仍然存在的已解决讨论串，并让确实待处理的讨论串保持未解决状态。
2. 验证变更。 清单模式（--manifest）：加载 references/MANIFEST_MODE.md，并按其中说明，根据 PR 头部验证清单契约——完全跳过通用审查器组。**无清单模式：**对审查范围（见下文 审查范围）运行通用审查器组。两种模式下，都要依据其延续规则执行判断检查（见下文）。
3. 发布结果。 将仍然成立的新发现作为一条 GitHub 审查提交，决定为 comment。讨论串回复发布在现有讨论串中，而不是作为新的审查评论。最后附上下面的周期摘要。

每次调用都从 GitHub 状态和当前检出开始。

每次调用都会验证变更。 是否再次运行 review-pr 由操作者决定——通常值得对高风险变更再读一遍，并换用不同的模型——因此，即使我们已经审查过且期间没有任何变化，新的调用也会重新审查当前头部。此时审查范围是完整 PR 差异，下面的筛除步骤会确保这一轮只补充新内容：如果第二次审查只是表示赞同，就不会发布任何内容。

唯一会跳过未变更头部的情况，是 --loop 在该调用首次检查之后唤醒（references/LOOP.md）：此时没有人重新作出决定，并且每次唤醒都重新审查同一个提交，正是这项检查要防止的无谓打扰。

审查范围。 下界是 GitHub 状态中记录的、我们最近一次对此 PR 进行审查时的头部；如果是该调用首次检查之后的 --loop 唤醒，则下界是该调用最近一次检查点的头部。若当前头部已超出下界且仍基于该下界，则审查 下界..当前头部。否则审查完整 PR 差异：没有先前审查记录时、新调用遇到头部未变时，以及变基或强制推送导致头部不再基于下界时，因为此时该范围已无法描述 PR 的变更。如果自下界以来已将基分支合并到头部，下界..当前头部 也会把基分支的提交当作 PR 的提交：审查 PR 自身差异从其合并基点到头部的内容自下界以来增加了什么——即当前差异与下界处差异之间的变化；如果无法确定这一对比，则审查完整 PR 差异。

逐讨论串验证

此验证覆盖我们创建或回复过的每个未解决讨论串，以及由我们的发现引发、但由此账号以外的人解决的每个讨论串——解决操作本身并不能说明问题已消失，因此要像回复一样进行验证。此类已解决讨论串每次调用验证一次：在 --loop 唤醒时，只有当记录其处置的检查点之后有回复、涉及其范围的提交或新的解决操作时才验证。带有判断标记的已解决讨论串则由 判断延续 恢复。对每个讨论串，调用 review-pr-thread-verify 技能。提供该讨论串的证据：

• 原始发现：锚点、正文、评审提交／头部 SHA，以及具体问题。
• 讨论串是否已解决，以及由谁解决。
• 自上次发言以来，该讨论串中作者的每条回复，以及我们此前在该讨论串中发布的每条回复。
• 锚点处的当前代码及其附近上下文，以及原始评审之后涉及相关范围的所有提交。
• PR 的完整历史：所有评论、评审讨论串、提交消息、当前 PR 描述，以及我们此前发布的评审／评论正文。
• 每个关联 PR（≤5）的上下文包：差异、描述、顶层对话。
• 对于判断类讨论串，相关的项目方向和决策、此前的建议，以及该建议所依据的证据或已接受的权衡。
• 下方的语气档案，供其起草任何回复时使用。

它会返回且仅返回一种处置方式、一条简短理由，以及在该处置方式要求时起草的回复；对于判断类讨论，还会给出当前建议以及讨论是否已定。即使讨论串已解决，也要在周期摘要中保留该评估。按以下方式处理：

处置方式	未解决的讨论串	已由他人解决的讨论串
addressed-by-fix	解决讨论串；仅当起草了回复时才发布。	保持已解决；仅当起草了回复时才发布。
addressed-by-valid-reply	发布让步回复，然后解决。	发布让步回复；保持已解决。
false-positive-or-stale	发布纠正回复，然后解决。	发布纠正回复；保持已解决。
needs-our-pushback	发布回复；保持待处理。	重新打开讨论串，发布回复；保持待处理。
still-pending	保持未解决；不发布任何内容。	如果对方在我们提出异议后再次解决了讨论串，且之后没有修复或回复：保持已解决且不发布任何内容，因为我们的论据已在讨论串中。问题仍然成立：将其纳入周期摘要，并计入验收评估。

仅当发布前重新阅读时发现我们在该讨论串中的最新消息尚未表达拟发布的回复，才发布该回复——流程可能在回复后、解决前中断，或另一次调用可能已经发布了回复。然后执行对应行中的后续步骤。

调用方策略。 在无清单模式下，评估变更是否实现了其既定目的，并履行了适用义务，同时在其支持的使用场景和预期维护中不存在已证实的缺陷或重大质量成本。将这些主张传递给每项检查。等级描述的是证据；它们不是默认的验收条件。默认情况下，发布仍会选择 Medium+ 发现。显式调用可以选择其他验收或发布策略，包括 Low；应分别将两者传递给检查和汇总。清单模式则使用清单中的当前主张和必需策略。未纳入发布的发现不会因此被视为已解决，也不会停止计入验收评估。

评审团队。 仅限无清单模式；清单模式下完全跳过（references/MANIFEST_MODE.md）。针对评审范围内的每个必需维度，启用 review-code 技能；即使多个评审共用同一上下文，也要保留各维度的发现和结论。始终启用的维度：change-intent、code-bugs、code-design、code-maintainability、code-simplicity、context-file-adherence。根据差异内容添加：对类型化代码启用 type-safety；对源代码启用 test-quality 和 code-testability；对 API 接口启用 contracts；对 CI／基础设施／环境／迁移／工作进程／队列／密钥启用 operational-readiness；对文案启用 docs 和 prose-value；当评审范围修复缺陷时启用 defect-class——它评估修复的防护效果和受影响位置的覆盖情况，因此对不修复任何问题的变更不适用。是否属于缺陷修复由你判断：利用 PR 描述、提交和关联问题来确认是否正在修复缺陷。对于提示词／技能／Agent，另外运行一次并以相同方式启用 review-prompt 技能。 证据与范围。 每个维度都应聚焦于自身标准。根据具有约束力的要求、明确的排除项和权限限制来判断范围，并将这些信息提供给 defect-class，以便其判断获准采取的补救措施。作者对实现方式的偏好不属于此类限制。检查代码和相关证据；作者的解释或成功报告并不能证明行为正确。判断环节会使用下方输入，单独评估后果是否符合项目目的。

整体一致性检查。 所有必需的检查都返回后，汇总其发现。对于被评为 Low 的正确性或安全性故障，以及遭到破坏的具有约束力的承诺，应先根据其证据重新评定，再应用调用方选择的策略。仅按该发布策略筛选；在调用方要求时保留 Low 级发现；保留维度和严重性。调用 review-pr-holistic skill。将 BLOCKED 判定及其缺失的证据或权限保留在本轮摘要中；整合不能把未完成的评估变成干净结果。提供保留的发现、调用方选择的策略，以及以下内容：

• PR 历史：PR 上的所有评论和讨论串（包括我们在之前任何审查轮次中发布的评论）、作者最近在该分支上的提交消息，以及 PR 描述。
• 每个关联 PR 的上下文：差异、描述、顶层讨论。不包括关联 PR 的行内审查评论。
• 本次调用审查的范围——这是 fleet 的 defect 发现所限定的代码范围。
• 判断环节在其整份 PR 评估（见下文）中的评估和发现，包括已解决的分歧。这些内容与 fleet 的发现一并整合，但不受调用方严重性筛选或审查范围限制——判断环节会自行读取整个 PR 的 head，因此其发现已涵盖整份 PR。
• 调用方做过的任何截断，并将其一并传递。
• 下方的语气风格配置。

它会剔除 PR 已涵盖的内容，去重不同审查者的发现，将缺陷发现从属于同一问题表面的判断问题（前提涵盖），将缺陷发现限制在审查范围内，为每条保留的发现提供依据锚点，并按语气风格配置改写每条评论正文。它会返回待发布的评论（锚点 + 符合语气要求的正文）、摘要标题文本（如有）、截断说明、附有主要原因的简短剔除发现统计，以及供操作者参考的判断评估。剔除评论不会抹去其保留的建议。

判断环节（项目后果）。 两种模式下都会运行；清单模式通过 references/MANIFEST_MODE.md 接入。整合前，单独启动 review-pr-judgment skill 进行评估。根据可用上下文、文档和关联讨论，查明项目目的、目标用户、目标及适用的决策，并遵循相关指引。传递来源及其理由，而不只是作者请求的摘要；指出重要的信息缺口。这既不需要 Manifest，也不要求特定文件名或设置工作流。将这些输入与 PR 描述、讨论、关联 PR 上下文（差异、 描述、顶层讨论）、完整 PR-head 差异（base..head）以及找回的先前判断和处置结果一并提供。由该 skill 负责评估及发现的格式。在无清单模式下，其发现和评估会经由整体一致性检查流转；问题则通过现有语气风格、判断标记和单次批量 comment 审查发布。 判断延续。 从持久化的 GitHub 状态中恢复此前的判断结果、回复和已定结论， 包括已解决的、带有判断标记的讨论串。此前的标记可以避免重复，但不能免除对新后果的评估。将当前提案和相关证据与此前评估所考虑的内容进行比较；针对重大变化和此前未评估的问题，结合整个 PR 重新评估。若新信号足以支持继续讨论，请在现有根评论的讨论串中接续；只有独立的新问题才需要新评论。将有依据且未变的评估（包括已定论的分歧）一并保留，无需再次发布。新的明确审查可以在同一 head 上发现新问题；未变化的循环唤醒不应重复已完成的评估。在调用检查点中记录建议、依据、限制和讨论串的处理状态，避免将沉默或问题解决推断为认可。

语气。 每条评论只表达一个观点：说明问题，内联指出证据（文件:行号；若代码片段是关键依据，则附上简短片段），并建议修复方案。直接、具体，不使用缓和措辞。

已发布的正文、标题或讨论串回复中绝不可出现：严重性标签（[High]、⚠️、Critical:）；任何表情符号；用于修辞的破折号表达（“这不只是 X —— 而是 Y” / “不只是 A，还有 B”）；缓和措辞（“我认为”“我建议”“看起来”“或许可以考虑”）；开场套话（“很棒的 PR！”“改动不错，不过……”）；“在上述位置” / “如前所述”（始终内联注明文件:行号）；AI 声明页脚。

结构默认规则：单条建议使用散文，不用项目符号；若评论只表达一个观点，不加 Markdown 标题，也不加粗重点。若评论确实涉及多个不同观点或并列事项，可使用标题和项目符号。

目标语气：“空输入会跳过空值检查：parser.ts:42 中的 if (input?.value) 会在 parser.ts:47 的解析之前短路，因此 {} 会未经保护就传入 parse()。请改为 if (input?.value != null)，或将 parse() 调用移入现有分支。”

发布评论。 整体审查完成后若有评论需要发布，应提交一条 GitHub PR review，决定为 comment，并将所有评论原子性地批量提交。提交前，重新读取带有我们标记的 PR 评论，删除其中已被本轮读取 PR 后发布的评论所涵盖的问题，避免同一 PR 上同时运行的第二次调用重复发布相同发现；在周期摘要中列出删除的评论。在 CI 或非交互环境中，不要等待批准。

没有待发布的评论。 只有在必要评估支持接受、没有有依据的实现缺陷或重大验证不确定性、所有必要维度均已完成且没有 BLOCKED，并且我们提出的所有缺陷讨论串均已终结时，才报告实现没有问题。任何待处理的判断讨论应单独报告；它不会改变对实现的接受结论。整体审查若要剔除问题，必须有证据支持的处理结论；仅通过发布筛选不能消除缺陷。否则应报告未解决的问题或证据阻塞，继续独立审查，不要表示批准。实现接受结论与判断建议应分别报告：已定论的咨询性分歧不会导致接受失败，但也不代表无保留认可。只有在接受实现后，交互式会话才可提出批准；如有保留的不利判断或重大的判断限制，应在问题中明确说明。若没有，则询问："Looks good to me. Post as approval on the PR?"。获得明确确认后，提交决定 approve，并在正文中保留任何已说明的保留意见；若用户拒绝，则不对 PR 采取任何操作。在 CI 或非交互环境中，不采取批准操作。 周期摘要。 每次单次运行结束时，都要向操作者提供摘要，无论是否发布了评论、解决了讨论串、请求了批准，还是没有发现需要处理的内容。首先说明操作者必须作出的决定或采取的行动：判断建议、实施验收，或不予验收的发现及证据阻碍，以及任何审批问题。然后简洁但完整地列出其余内容：

• 判断环节：建议、依据和重要限制；已发布或继续跟进的问题，或 none；以及任何已解决的分歧。区分继续推进的决定与审阅者的认可。说明本次是重新评估，还是沿用之前的判断，并解释原因。清单模式也适用。
• 使用的审阅上下文、已审阅的范围／提交，以及采取的具体 PR 操作：新增审阅评论的数量及锚点、讨论串回复、已解决的讨论串、批准提示／操作，或未对 PR 采取操作。
• 本轮是重新审阅了我们之前审阅过的提交，还是审阅了新的差异；若是重新审阅，需区分新发现的问题与已覆盖而不再列出的问题——这是区分第二次审阅后达成一致与从未进行第二次审阅的唯一依据。
• 逐个讨论串核验：每个讨论串一行，注明锚点、处理结果和核验者给出的简短理由。
• 审阅者队列（非清单模式）：每个发现问题或状态为 BLOCKED 的维度各占一行，注明其判定、可采取行动的发现数量及内容；若为 BLOCKED，还要注明缺失的证据或权限；另用一行汇总没有发现问题的维度。清单模式下，则按 references/MANIFEST_MODE.md 报告各项标准的核验结果。
• 整体一致性审查（非清单模式）：保留的评论、去重／合并情况、按主要原因精简的发现、范围界定决定、摘要标题（如有）以及截断说明。

周期摘要仅供操作者的对话记录或运行日志使用。不得将其粘贴到 PR 审阅正文、讨论串回复或批准文本中；唯一可发布的类似摘要文本，是整体审查环节返回的、符合语气要求的摘要标题。

发布限制。 批准必须遵循上述明确的用户确认流程。绝不提交 request_changes，绝不重新发布未修改的精简后发现，也不得放宽去重标准以产出内容。即使代码审阅范围为空，也要继续处理现有讨论串。

--loop。 加载 references/LOOP.md。