用途：kiro-review 用于任务级对抗式审查，核验实现是否真实、完整、受边界约束、符合已批准的需求与设计，并有机械验证证据支撑。适用时机包括实现者报告 READY_FOR_REVIEW 后、被拒审查的整改后、将任务标记为 [x] 前，以及任务进入特性级验证前。不得用它臆造缺失需求或静默重释规格。
主要能力：先运行 git diff 查看实际改动，必要时直接读取变更文件，不把实现者报告当作事实来源。机械检查包括：运行项目规范测试套件（失败即拒）、检查变更文件中是否新增 TBD/TODO/FIXME/HACK/XXX 占位标记、是否硬编码密钥、改动是否越出任务 Boundary: 范围、行为类任务是否提供 RED_PHASE_OUTPUT、以及针对运行时敏感模式的静态检查（如类型导入被当值使用、限定名访问缺少命名空间值导入、未解析全局变量、新增运行时敏感依赖缺少启动处理）。判断检查包括：实现是否为真实生产代码、验收标准覆盖、需求对齐、设计对齐、边界审计（对照 localized-spec-terminology.md 中的边界与越界术语，拒绝把下游行为推入上游边界、新增隐藏依赖或未声明耦合、非集成任务表现得像集成任务）、测试质量（测试能否在实现被移除或破坏时失败）、错误处理。
使用方式：需提供任务 ID 与 tasks.md 中的确切任务文本、相关需求与设计章节号、规格文件路径（spec.json、requirements.md、design.md，可选 tasks.md）、localized-spec-terminology.md、实现者状态报告、任务 Boundary: 约束、控制器发现的验证命令，以及相关 steering 摘录和 ## Implementation Notes 条目。输出 APPROVED 或 REJECTED，并附机械结果、带严重级别的发现、必需整改与一句话总结，语言按 spec.json 指定。严重级别为 Critical、Important、Suggestion、FYI。当规格在正确性关键处含糊、设计与技术可行性冲突、无法收集所需证据、实现只能靠静默偏离已批准范围才能工作、或边界归属无法清晰判定时，应升级而非掩盖。
限制：资料未提供具体安装命令、收费方式、支持平台或性能数据。