review-work

审查工作

基于证据和技术判断审查所请求的产物。除非用户明确要求修复或实现，否则此技能为只读。

使用 workflow-language.md、review-language.md、document-conventions.md，并在相关时使用 research-ladder.md 或 architecture-language.md。

确定范围

在判断发现的问题之前，先确定主要审查对象、比较基准、边界和所需审查力度。对于分支或差异审查，在进行耗时分析之前，先确定比较基准，并确认目标范围非空。只有在无法安全地确定边界时才提问。

• 计划审查模式：判断计划是否连贯、可执行、范围明确且可验证。检查依赖关系、任务与验收标准的覆盖情况、前置条件、已锁定决策之间的矛盾、跨计划所有权、审查安排、验证和文档生命周期。除非计划无法安全执行，否则不要要求实现证据、润色文案、穷尽边缘情况或重新设计架构。
• 实现审查模式：从具体代码、测试、文档、差异或交付产物入手。将相关计划和当前文档作为事实依据，而非主要审查对象。
• 后续审查：聚焦已接受的修复、补丁说明、变更范围、未解决的风险，以及不应重新讨论的已定事项。
• 独立审查：用于明确要求的交叉验证，或强制要求的全新上下文实现审查。在实际可行时，先检查一手证据，再查看此前的发现或作者结论；之后再对照核验。由于独立性是有意为之，审查结果可能与此前发现重叠。
• 临时审查：针对用户指定的文件集、功能、分支、提交或非代码产物，灵活采用同样的证据优先方法。

评审方法

1. 阅读仓库说明和权威资料。
2. 根据风险需要，检查实际目标及其调用方、测试、文档或运行时行为。当更改涉及环境变量、机密信息、端口、脚本或设置命令时，应追踪受影响的开发者运行／构建路径，将其视为调用方可见的契约。
3. 通过代码、差异、架构、命令、一手文档或有针对性的运行时检查来验证假设。
4. 检查正确性问题、需求遗漏、不安全的生命周期行为、文档偏差、测试缺口、安全／数据丢失风险，以及实质性的可维护性问题。
5. 报告前，先协调重复或相互冲突的证据。

对于全新实现的评审，应进行审慎的结构简化检查：确认是否存在可避免的概念、分支、可变状态、间接层，或是否有实质上更简单的设计。只报告具体且适度的问题；这不是独立的评审人员、固定的规模门槛，也不预设存在阻塞问题。

当更改涉及共享契约、持久化、安全、并发、部署或广泛使用的接口时，可将影响范围作为一种可选视角。使用这一视角时，应按风险程度追踪受影响的调用方和使用者，明确变更安全性依赖的一两个不变量，并通过成本最低且稳定的真实接口加以证明。凡未经证明的内容，都应作为剩余风险报告；默认不要进行全仓库影响扫描。

默认进行平衡的评审。只有在用户提出要求，或风险和不确定性在很大程度上足以证明其成本合理时，才增加对抗性分析、多视角评审、子 Agent、调研或额外轮次。除非选择会实质性改变范围、延迟或成本，否则应自行判断适用的视角，不要询问用户。

子 Agent 的报告只是线索。主评审者必须依据一手证据核实每项实质性采纳的主张。不要递归地委托其他评审者评审本次评审。

没有最低问题数量要求。在充分覆盖的基础上，评审结论也可以是未发现问题。合并重复问题，并通常将可执行的问题控制在约 15 项以内。

强制性阶段评审

对于阶段结束评审或直接实施评审：

• 独立评审者必须获取全新上下文；
• 评审范围应涵盖整个阶段或等同阶段的实现，而不只是最新补丁；
• 计划中定义的高影响检查点不能取代此评审；
• 只有在用户另行授权实施后，才能修复发现的问题；
• 修复后，仅针对变更涉及的范围和剩余风险，重新进行有依据的评审。

文档与产物生命周期

对于基于计划的实施，只检查当前计划负责的草稿和文档差异项。无关草稿可以指出，但不应阻碍收尾。

将文档偏差作为问题报告；不要悄悄修改。轻微的事实性偏差可以建议直接修正。涉及产品的敏感或实质性偏差，在决定或实施之前会阻碍收尾。

若仍有阻塞问题、验证未完成、计划负责的文档工作未完成，或实施尚未完成，不要提出删除计划。已完成的计划若不在当前路线图中，应在最终评审和文档同步后询问一次是否删除。若当前路线图引用了该计划，则报告已具备完成条件，并将计划／路线图的变更留给另行授权的工作流程步骤；路线图收尾是清理的前提。切勿自动删除。

输出

按严重程度排序，首先列出已验证的发现。每项发现都应包含精确的文件/行号或命令证据、问题的重要性、具体影响以及建议的修复方案。区分明确缺陷、合理权衡和所有者策略决策。

对于实质性审查，请提供简洁的审查记录：

• 范围与验证
• 审查信号：High、Medium 或 Low
• 建议
• 剩余风险

仅在适用时添加 Plan、文档、轮次、协调或下次审查等字段。对于简单的临时检查，只需简明结论，并说明范围与验证情况。不要提供 N/A 模板或冗长的逐字记录。如果没有任何发现成立，请明确说明，并列出覆盖范围和限制。