code-review

代码审查

检查改动是否实现需求、逻辑自洽、影响面完整，或指定模块是否兑现其功能契约。默认只读，给出结论和建议；已有明确修复授权时执行该范围，不重复询问，也不自动扩展到整理工作树、提交或发布。

适用于不同项目与技术栈。按项目实际使用的语言、运行库、构建与验证能力选择证据；界面、并发、持久化和模型工具等检查只在相关模块存在时适用，不预设特定产品、SDK、框架、命令或目录结构。

先确认范围和基线

用户指定的提交、区间、工作树差异或模块优先。没有临时指定时，默认检查当前分支未推送的提交。项目已明确发布远端和分支时遵循该约定，可显式使用已核实的引用；否则再核对分支与远端/跟踪关系。记录实际比较的基线及终点，不将某项目的远端约定推广到其他项目，也不认为本地远端引用一定最新。

同时区分提交、暂存、未提交和未跟踪内容，不把其他在制改动算成本次交付。范围有影响结论的歧义时澄清；可确定的部分继续，不默认扫全仓。无 Git 项目按指定源码范围检查，不要求初始化仓库。

按需加载方法

• 变更审查、修复复核、断言有效性：读取 references/change-review.md。重点是需求对账、逻辑/安全、列举清单、旧数据和变更归属。
• 模块、页面或子系统审查：读取 references/module-audit.md。重点是实际入口、声明/实现/消费、关键字段与用户结果的闭环。
• 组合任务：沿用户目标补充另一份参考，避免把模块审查扩大为全仓重构。

本技能自带所需参考，可独立使用。若本次已有其他审查或健康检查结果，复用已取得的证据，只补未覆盖的相关风险，不依赖额外技能存在，也不重复执行整套审查。

结论的最低证据

把用户要求、验收条件和说明中的声称对应到实际路径及结果。每条问题给出触发条件、位置/输出证据、预期与实际差异、影响和建议；区分已复现、源码可确定和未验证。部分完成时明确差额。

检查按名称枚举的注册、校验、保护和显示映射；接口变化追踪声明、实现、调用方及已有数据。第三方行为按实际版本核对；合并 diff 不用于单独证明历史引入者。

修复复核关注守护能否拒绝已知错误实现。反向探针在隔离环境中执行，确认失败原因属于目标行为；不能用改坏用户工作树、通用失败或恒真反例证明测试有效。

对 UI，尺寸等可量化结论用计算值，视觉与交互判断结合实际渲染；无渲染条件时标注推断，不把截图作为每次审查的固定要求。

环境提供 web-ui-metrics-verify 且本次涉及 Web UI 几何或视觉量测时，优先复用其方法；不可用时使用项目已有的渲染/浏览器验证工具，不要求安装该技能。

修改和验证边界

只读审查不修改源代码、暂存区或历史。已授权修复时保留其他在制改动；发现同文件有其他修改先看实际 hunk，不机械地全部停工，也不移动、覆盖或一起提交它们。

运行与本次风险相关的项目检查，再完成约定的验证。区分源码、环境、其他改动和平台原因；退出成功或测试数量不代表结论已被证实。只有新变化、失败或未解疑点才扩大或重复验证。

需要 Git 修复、提交拆分或历史整理时，按该动作的实际授权处理；stash、整文件还原和重写提交不作为默认审查步骤。审查技巧不能替代对用户工作成果的保护。

输出

有问题时先给有证据且可行动的发现，再简述范围、验证和限制。没有发现时明确检查过什么、未覆盖什么，不宣称软件没有缺陷。

沿用项目严重度标准；没有标准时采用 references/change-review.md 中的默认 P0/P1/P2 分级表，并说明影响及触发条件。分级定义只维护在该参考文件中。

风格偏好和无证据的未来风险与缺陷分开。只读审查写建议，不写“已修复”；修复后报告具体变化与验证结果。