Dsh Code Review skill

按真实行为要求审查代码

阅读项目上下文、验证证据以及改动区域的实际需求。除非用户要求修复，否则保持只读。未经用户授权，不向外部发布审查意见。

1. 明确准确的基线与目标提交，或本地差异及暂存、未暂存等修改层。审查远端 PR 时获取其当前引用；目标分支或内容更新后重新确认。
2. 将变化的接口对应到实际数据提供方和调用方。判断差异前，阅读周边代码、相关决策和项目必需检查。
3. 优先检查正确性、安全、生命周期和必需行为是否损坏。资源或错误处理变化读生命周期；异步测试读测试可靠性；可见界面读UI；文字变更读文档写作。默认值、校验、依赖或抽象变化读编码规范；覆盖率或测试设计问题读测试选择。
4. 追踪校验是否真正保护了目标操作，包括其他入口和直接调用方。检查边界值、最终输出或保留内容的大小，计入元数据和多字节文本。核实取消、部分成功、资源释放和派生状态。
5. 检查实际交付入口、公开导出、构建是否为当前版本以及真实测试证据。重要结果应有独立断言，新增约束应有会失败的错误样例。检查全绿或作者自述不能代替语义审查，也不要无故重跑无关的高成本检查。
6. 检查必要性：每个抽象、兼容分支和通用 API 都应有当前行为要求或调用方。不要仅凭文本搜索结果猜测并移除受支持行为。
7. 确认当前文档、默认值、错误和界面文字与代码一致。翻译改动已经在范围内时检查含义，不自行启动翻译任务。

只报告可采取行动的问题，包含文件和行号、具体触发条件、影响及证据。区分缺陷与可选建议，不为凑数量而编造问题。没有充分依据的问题时直接说明，并指出重要覆盖限制。审查发现不等于获得修改或推送权限。

报告验证结果前，将每项“已经执行”的说法对应到真实工具调用和结果。代码推理可以支持发现，无需假称执行过测试；标明这是静态检查。建议检查写“未运行”，用户提供的历史日志注明来源。不得编造成功命令或工具拒绝。