用途
review-spec 用于对技术规格文档（technical specification）进行评审，评审深度为“设计落地”（design-landing）级别。它从五个维度给出评分与问题清单，并最终给出一个门禁结论，用于判断该 spec 是否可以进入实现阶段。
该技能与 /codex-review-doc 同属一个评审门禁下的文档面产出者，二者通过相同的 Codex exec 传输通道（@skills/codex-code-review/references/codex-transport.md）分发，并输出相同的 sentinel 对。区别仅在评审深度和维度：/review-spec 覆盖完整性、可行性、风险、代码一致性、测试策略，属于设计落地深度；/codex-review-doc 属于通用文档深度。循环机制、严重度校准与 [NIT_DEFERRED] 处理逻辑是共享的。
触发方式
关键词包括：review spec、spec review、tech spec review、review-spec。
不适用场景：
- 代码评审（应使用 /codex-review-fast）
- 通用文档评审（应使用 /codex-review-doc）
- 撰写新 spec（应使用 /tech-spec）
主要能力与评审维度
技能会要求评审者独立阅读并调研项目，而非依赖预先提供的文件内容。评审维度包括：
- 完整性（Completeness）：需求、范围、风险与工作拆解是否齐全且具体。
- 可行性（Feasibility）：所述内容能否按描述构建，所依赖的依赖项是否具备。
- 风险评估（Risk Assessment）：是否识别出真实失败模式，且每种都有约束边界。
- 代码一致性（Code Consistency）：引用的文件/函数是否存在且行为与描述一致（通过 grep/cat 验证）。
- 测试策略（Test Strategy）：每条验收标准是否映射到证据；守卫是否双向。
评审过程包含代码与文档一致性调研步骤，例如在仓库根目录执行 ls 探查真实结构（不假设存在 src/ 布局）、用 grep 搜索 spec 中提到的每个文件、函数、标志和命令、读取相关文件并核对引用文件是否存在、名称是否正确、描述行为是否与代码一致。
严重度校准
🔴 级别为阻断项，会挡住文档并消耗一整轮评审，仅用于会误导读者构建错误东西的缺陷，例如：描述的文件/函数/标志/命令不存在；描述的行为与代码实际行为矛盾；安全或数据处理设计错误或不安全；内部矛盾（两段内容无法同时成立）；损坏的交叉引用，或某步骤所述依赖无法由其自身顺序满足。
不应标🔴的情况包括：措辞可以更清楚；你会有不同结构安排的段落；没有规则要求的缺失小节；可用表格呈现更整洁的行文；当前变更中不存在的假设性未来顾虑。
技能明确要求不要为了填充章节而制造发现项，空的🔴章节是正常结果。
输出格式
报告必须以字面行 ## Document Review 开头。报告包含：评审摘要（各维度 1-5⭐ 评分与备注）、🔴 Must Fix（阻断项，若无写 None）、🟡 Suggested Changes（非阻断）、⚪ Optional Improvements（可选改进）、Deferred Findings（对每个🟡和⚪输出一行 [NIT_DEFERRED]，格式为 [NIT_DEFERRED] <file:line> | <issue> | reason: sub-threshold-doc | <ISO8601 UTC>，字段顺序不可调整，若无🟡或⚪则完全省略该节），以及 Gate 结论。
Gate 结论必须是报告最后一行、单独位于第 0 列的唯一终止行：无🔴发现 → 最后一行 ✅ Mergeable；有任何🔴发现 → 最后一行 ⛔ Needs revision。作为列表项时不是合法的终止行。
使用方式
任务部分接收待评审文档：$ARGUMENTS。若未给出路径，则自动检测：docs/features/ 下 git 修改的 2-*.md → 暂存的 .md → 最新的 tech spec。若存在多个候选，会列出并询问要评审哪一个。
技能会先绑定所有占位符（如 ${FILE_PATH}、${PROJECT_ROOT}）再写入 prompt.md，因为 prompt 正文为 body-only，不会被求值，占位符必须携带真实值，否则指令会以字面文本传给 Codex 而无法执行。分发按 @skills/codex-code-review/references/codex-transport.md § Start 执行，传输层固定 sandbox 和审批策略。返回的 threadId 需保存，循环复审会在同一线程上继续。
门禁含义与限制
✅ Mergeable 表示无🔴项，spec 可进入实现；⛔ Needs revision 表示存在🔴项，需修复后在同一线程上复审。🔴 之外，🟡 和 ⚪ 为非阻断，通过 [NIT_DEFERRED] 记录并继续。轮次上限及其 ## Max Rounds 覆盖来自共享契约；仍然失败时应报告阻断原因，而不是再消耗一轮。
该技能的 verdict 属于行为层，来自评审者的报告，review-state.js 只记录显式 note，没有 hook 解析评审者输出。有一个机制会机械读取 sentinel：scripts/validate-family-sentinel.js doc 会在其 verdict 被采纳前验证 fallback carrier 的原始报告，因此 sentinel 形状在两个方向上都固定，转述对人类读起来像没有 verdict，对验证器则直接失败。
验证清单包括：通过 Codex exec 传输分发而非 Agent；prompt 要求 Document Review 且报告以该头开头；Codex 独立验证代码-文档一致性；Gate 取值为 ✅ Mergeable / ⛔ Needs revision 之一。
适用场景
适用于在技术方案定稿落地前，对技术规格文档做设计落地深度的评审，尤其是需要校验 spec 中对仓库文件、函数、命令的引用是否真实存在并行为一致时。
限制与暂未提供
不适用于代码评审、通用文档评审和撰写新 spec。关于具体安装命令、配置项、收费或价格信息，当前资料暂未提供。