三模式代码审查

要解决什么问题

在 tri-coding / tri-fix 落地改动，或你直接对着分支、PR、git diff 做 review 时，常见困境是：规格有没有被完整实现和实现质量是否达标被混在一轮对话里扫过，BLOCKER 级偏差也可能在「看起来能跑」之后才暴露。增量改动若缺少架构语境，还容易在模块边界、契约和隐性需求上悄悄偏离设计。

本技能是 tri-intent 的下游执行 skill（@user_989eb8f0/tri-review），把 AI 固定在「审查专家 + 系统架构设计师」角色：只审查/审计，不改代码；问题写入 review-report.md 或 audit-report.md，修复由 tri-coding / tri-fix 承接。

如何工作

激活后先判定模式，再读输入，不得跳门抢跑：

• 工作流集成：读 .tribro/coding/ 或 .tribro/fixes/ 链路文档作规格来源。
• 独立调用：读快照 §三 结构化结论（经 tri-intent 澄清后）。
• 增量审计：文档驱动学习设计意图，默认当前项目与工作区 diff。

流程上串行经过两道落盘审批门：门①锁定固定点、规格/标准来源与 diff 命令；门②汇总报告待你确认。

| 阶段 | 核心问题 |
|------|----------|
| Phase 0（增量审计） | 设计意图是否偏离？三维：代码设计改动 / 架构设计实现 / 功能设计实现 |
| Phase 1 | 做了对的事吗？功能完整性、行为正确性、需求对齐、上下文一致性 |
| Phase 2 | 做得对吗？结构、可读性、健壮性、性能、安全、测试 + Fowler 12 坏味基线 |

铁律：Phase 1 未通过不得进入 Phase 2；Phase 2 发现的功能性缺陷可推翻 Phase 1。清单项用复选框记录「是否已审查」，与 PASS/FAIL 分离；覆盖度账本双源记账（self_reported / machine_observed）并维护 gaps，避免「没查」冒充「查了没问题」。

边界与注意点

• 不负责：意图识别（tri-intent）、编码（tri-coding）、修 bug（tri-fix）、按报告改代码。
• 独立安装且无可用快照时，会引导 tri-intent；拒绝安装则降级模式下增量审计仍可跑，标准审查的规格识别精度会下降。
• 执行入口有版本检查硬门（连接 skillhub 校验，非最新可自动升级）；任一门未通过须携反馈回炉，不得跳过 Phase 或合并阶段（反规避机制会标 [INVALID:*]）。