spec-review

name	spec-review
description	在需求进入审查阶段后，对照已确认的 `spec.md`、`tasks.md`、`log.md` 与实际代码执行两阶段代码审查。用于用户要求做 review、核对实现是否符合 spec、进入 review 阶段、先查功能一致性再查代码质量、输出 Critical/Important/Minor 问题，或决定是否回退到 `spec-apply`/`spec-fix` 修正时使用。

spec-review

协同技能

在执行本 skill 时，同时遵守 ../../references/full-sdd-lifecycle.md 中 spec-review 阶段的协同规则。

• 审查结构优先继承本插件 skills/code-review-and-quality/SKILL.md
• 触及安全边界时补读本插件 skills/security-and-hardening/SKILL.md
• 触及性能或容量要求时补读本插件 skills/performance-optimization/SKILL.md
• 本 skill 负责先做 spec 一致性门控，再决定是否进入质量审查

目标

执行 AI 主导的两阶段审查，并把“是否通过”建立在代码证据上，而不是建立在报告、口头说明或实现者自述上。

• 阶段一只回答“实现是否符合 spec”
• 阶段二只回答“在符合 spec 的前提下，代码质量是否达标”
• 任一阶段 FAIL，立即停止后续阶段并给出回退建议

进入条件

执行前先确认以下条件成立：

• 已存在对应需求目录，且至少能读取 spec.md
• 若存在 tasks.md、log.md，一并读取并用于理解上下文，但不要把它们当作事实来源
• 当前代码已经进入“待审查”状态，而不是仍在设计或尚未开始实现
• 用户明确要求 review，或要求核对 spec 落地情况、做质量审查、决定是否可以交付

若以下任一情况成立，停止审查并说明原因：

• spec.md 缺失或仍存在关键待确认项
• 实现明显尚未完成，不具备审查前提
• 需要先补变更上下文、规则文档或测试基线

执行顺序

按以下顺序执行，不要跳步，不要把两个阶段混在一起。

1. 锁定审查输入

先收集最小必要上下文：

• 读取需求目录中的 spec.md，必要时补读 tasks.md、log.md
• 直接读取相关实现、测试、接口定义、页面或配置
• 读取仓库规则：docs/rules/README.md、docs/rules/project-context.md
• 进入阶段二前，再按需读取 docs/rules/code-style.md、docs/rules/ts.md、docs/rules/security.md

执行时坚持下面约束：

• 不信报告，只信代码
• 不把 log.md、提交说明或人工总结当成完成证据
• 只按已确认 spec 审查，不擅自扩展需求

2. 阶段一：Spec Compliance

此阶段由 spec-reviewer 视角执行，只检查“做没做到”，不讨论风格优雅与否。

执行要求：

• 将 spec.md 中的功能点、流程、边界、非目标、验收条件拆成核对清单
• 针对每一条，在代码、测试、接口或运行路径中寻找直接证据
• 证据不足时，结论应为“未证实”，不要主观脑补为“应该支持”
• 若发现行为缺失、行为偏离、验收点未满足、关键路径无证据支撑，判定阶段一 FAIL

阶段一输出至少包含：

• 总结论：PASS 或 FAIL
• 逐条核对结果：已满足、部分满足、未满足、未证实
• 每条结论对应的代码证据或缺失说明
• 若 FAIL，明确建议回退到 spec-apply 或 spec-fix，并停止阶段二

3. 阶段二：Code Quality

只有阶段一 PASS 后，才允许进入此阶段。此阶段由 code-quality-reviewer 视角执行。

检查重点：

• 是否违反 docs/rules/ 中的长期规则与分层约束
• 是否存在安全红线、输入校验缺失、异常处理缺口、边界泄漏
• 是否引入明显 bug、行为回归、脆弱实现或难以维护的耦合
• 是否缺少支撑关键行为的测试或验证
• findings 的组织方式尽量与本插件 skills/code-review-and-quality/SKILL.md 的严重度和证据要求保持一致

输出要求：

• 先给 findings，再给简短总结
• findings 按严重度排序，只使用 Critical、Important、Minor
• 每条 finding 都要说明问题、影响、触发条件和代码位置
• 若没有发现问题，明确写出“未发现需要报告的 findings”，并补充剩余风险或测试空白

4. 汇总结论与回退路径

最终结论只能是以下三种之一：

• 阶段一 FAIL：实现未达到 spec，回退到 spec-apply 或 spec-fix
• 阶段一 PASS、阶段二 FAIL：功能达标但质量未过门禁，回退到 spec-fix 或定向修复
• 两阶段均 PASS：审查通过，可以进入后续交付或合并动作

不要在以下情况下宣称“审查通过”：

• 关键 spec 条目没有直接证据
• 阶段一尚未 PASS 就提前做阶段二总结
• 存在未解释的高风险问题
• 受环境限制无法验证关键路径，但仍给出无保留 PASS

审查纪律

• 始终把代码、测试、接口和运行路径当作唯一证据源
• 先给结论，再给依据；依据不足时降低结论强度
• 发现 FAIL 后立即停下，不继续美化报告
• 用户如果只要求一个阶段，只执行该阶段；但默认执行完整两阶段

输出模板

向用户汇报时至少包含：

• 阶段一结论，以及逐条 spec 核对的核心结果
• 阶段二 findings，或说明因阶段一 FAIL 而未启动
• 最终结论：PASS / FAIL
• 建议下一步：继续交付、回到 spec-apply、或进入 spec-fix