full-review

全面审查

选择分支后再选择模型。仅协调者执行的审查和确定性证据工作在调用权限范围内进行。在分配的审查者上下文中应用常规审查视角。对于工作者调度，请使用 shared/references/model-preview.md 及其唯一获批的路由快照。嵌套技能、运行器和复查均使用该快照，不会另行选择路由或工作者。

对于工作者调度，模型 ID、支持的工作强度和任务默认值只能来自 shared/model-routing.json。在调度、重试和恢复期间，保留已保存路由的原样内容。

审查重点实现环节无法发现的风险。给出精准且有证据支撑的结论。后续使用者是作者或交付工作流。审查完成时，必须明确说明审查范围、证据、发现、验证局限和结论。

审查计划

审查计划是范围契约。不得声称覆盖计划范围之外的内容。计划规定 scope、risk、seats、effort 和 verification。在交付工作流中，应从用户批准的路由计划 JSON 推导审查计划。该 JSON 是指定审查席位、运行器、模型、工作强度、模式和不可用操作的精确可执行来源。

范围	适用情况	最低审查配置
focused	一项边界明确、局部风险较低的变更	一个审查席位及相关确定性检查。
seam	集成任务、共享契约或跨边界行为	经批准的一个或多个路由，覆盖逻辑和状态并精准定位根因。只有计划明确指定时才添加第二条路由。
deep	明确要求深入审查、安全敏感边界、迁移、公共契约或较高的剩余风险	seam 配置，加上选定的安全、数据、兼容性或结构方面的专家。

不要启动无差别审查小组。审查席位名称、模型选择、运行器和工作强度只能来自获批计划和模型清单。使用提供的或继承的审查模式与范围。否则，采用证据所支持的最窄安全范围。只有当选择会改变范围、成本、允许的影响或重要的未决决策时才提出询问。沉默不代表批准。外部路由计划获批前，不得调度该路由。用户直接要求深入审查，授权的是深入审查范围，而不是未经计划的路由调度。

对于没有匹配快照的工作者调度，model-preview.md 会使用 task-shaped-model-routing.md、 model-roster.md 和 host-model-execution.md 做出唯一一次选择。匹配的快照须原样使用。审查计划会注明最终路由；本技能不会用更方便的运行器或协调者模型替换它。

工作流

1. 明确目标：拉取请求、提交范围、本地差异、任务文件集或文档。差异为空也是一种结果，并非失败。现在选择输出约定。提供的共享审查快照使用 shared/references/reviewer-response.md 中选定的部分，或简报中嵌入的相同部分。独立代码使用 references/review_output_schema.json；独立文档使用 references/doc-findings-schema.json。只加载对应的架构。
2. 阅读当前上下文中已有的项目约定，以及影响变更路径的本地约定。收集差异、变更文件、相关上下文代码和现有审查评论。现有评论只是待核实的线索，并非事实。
3. 审查代码时，从此技能所在目录运行 scripts/review_scope.py。使用其风险信号确认或缩小计划；不要仅仅因为有辅助工具，就扩大聚焦审查的范围。
4. 只加载与所选关注点相符的参考资料：references/bug_finders.md、references/panel_roles.md、references/conditional_specialists.md 或 references/structural_quality_review.md。对于需求文档，只使用 references/doc-personas/ 中相关的角色说明。仅在实际派发工作者之前阅读 references/review-dispatch.md。
5. 常规关注点仅在指定审查者的上下文中阅读。只有当重大风险或未解决的问题确有需要，且已批准的快照指定了派发路线时，才派发独立专家。向每个派发席位提供相同的范围上下文、约定和输出约定。保持席位忠实度：无法使用的席位应记录为不可用，绝不能悄然替换。宿主提供独立持久子 Agent 或支持的任务上下文时，使用准确的原生模型和推理强度。仅当路线不受支持或属于外部路线时才使用运行器。保留每位审查者的上下文，以便后续复查，并将其与实现者及其他独立审查者分开。宿主支持时，并行运行独立席位。最终代码审查必须独立于实现者。
6. 在可执行的情况下，验证运行时、安全性、正确性、兼容性、可靠性和性能相关发现。根据变更代码核实结构性发现。将未经验证的主张标记为未经验证或降低其置信度；不能仅凭断言将其升级为阻断项。
7. 对于代码，阅读 references/filtering_pipeline.md。使用入口处选定的输出约定。去重，仅保留有证据支持且带有位置的发现，然后应用当前置信度阈值。持久保留每项已确认的发现；数量上限仅限制面向用户的摘要。精准优先于数量：不要报告外观偏好、宽泛的重构诉求或范围之外的既有问题。
8. 返回结论。默认仅报告问题。用户或调用方明确授权修复时，记录 apply_fixes: true 并在授权范围内应用修复；无需再次确认，也无需用户提供特定措辞。交付前审查变更路径。

安全与文档

当 security_focus=true 时，根据记录的安全决策检查实现，并且只纳入计划指定的安全和数据专家。不要为了满足评论数量上限而省略安全问题。

对于计划或需求文档，应审查可行性、范围、连贯性和决策缺口，而不是代码差异。遵循相同的范围约定和证据标准。

输出

当调用方提供 shared/references/review-evidence.md 中的快照时，请使用该共享契约生成完整的最终 JSON 响应。若简报中包含相应章节，则使用这些章节。否则，请阅读 shared/references/reviewer-response.md 中的简介、Initial response、Evidence packet substitution 和 Completion。对于源代码复查，添加 Recheck；对于补充说明，还要添加 Prose correction。只有声明了批次时才添加 Batch endorsement，且这要求完整响应。验收契约变更也要求完整响应。这些章节将取代独立架构和报告模板。任何人工报告都应与记录的 JSON 分开。 对于聚焦复查或补充说明，使用该契约中的增量响应协议。扩展记录必须涵盖每个快照路径，保留先前的问题 ID，并引用已捕获的检查和浏览器证据。将 CRITICAL、HIGH、MEDIUM 和 LOW 分别映射为 P0、P1、P2 和 P3。每个已确认的 MEDIUM 都对应一个待解决的 P2，直至证据将其关闭；展示上限不能将其移除。协调方记录实际响应并运行验证器；执行成功不代表审核通过。

对于没有共享快照的独立代码，请返回人工报告和符合 references/review_output_schema.json 的 JSON。对于独立需求文档，则使用 references/doc-findings-schema.json。只有这两种独立模式使用 references/review_report_template.md 作为报告模板。

在独立架构中，每条新增的代码问题都必须包含稳定 ID、状态（confirmed、unverified 或 refuted）、严重程度、置信度、类别、位置、证据、最小有效修复方案和验证方式。复查时须保留 ID 和处置证据。文档问题须包含章节和引用的证据。独立代码报告须以以下内容结尾：

Bugs found: N | Verified: X | Refuted: Y | Verdict: APPROVE|COMMENT|REQUEST_CHANGES

在单独的人工报告中说明所选范围、计划席位和无法提供的席位、已执行的验证，以及任何覆盖范围限制。对于独立审核结论，若仍存在严重或高严重程度的问题，则使用 REQUEST_CHANGES；若存在有意义的中等问题，则使用 COMMENT；否则使用 APPROVE。