메뉴
审查 Spec 执行完成情况，检验实现是否严格按照 Spec 执行，识别未完成项和不符项，在 reviewer/ 下生成审查报告（review.html）。在 spec-execute 完成 executor/summary.html 后、spec-end 归档前使用。`gated` 模式下可选，由 TeamLead 按需启动；`autopilot` 模式下强制介入（自动驾驶下唯一的独立视角）。触发词：审查 Spec、检查实现、Spec Review。
기본적으로 소스를 먼저 확인하는 Prompt가 선택됩니다. 직접 명령으로 전환하거나 로컬 사본을 다운로드할 수도 있습니다.
설치 여부를 결정하기 전에 SKILL.md와 SkillsMP에 표시된 보조 파일을 읽어 보세요.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
직접 명령은 검토 Prompt를 거치지 않습니다. 실행하기 전에 소스를 확인하세요.
npx skills add https://github.com/HHU3637kr/skills --skill spec-review명령은 한 줄로 유지됩니다. 복사하기 전에 가로로 스크롤해 전체 내용을 확인하세요.
로컬 사본을 원하시나요? SkillsMP에서 현재 제공할 수 있는 파일을 다운로드하세요.
SKILL.md 표시 중
当用户开始新的开发任务、需要启动完整 Spec 流程（需求对齐→探索→设计→实现→测试→收尾）， 或需要为一个新 Spec 创建协作上下文和 GitHub Flow 工作分支时使用。 不要用于已有完成 Spec 的小迭代（用 spec-update）或项目首次初始化（用 spec-init）。
当用户要求以「Agent 主控 + 全程 spawn 子 Agent」的方式启动 R&K Flow 开发流程时使用： 当前 Agent 只做编排（账本、门禁代问、批次调度），七个角色的实质工作一律交子 Agent 执行。 典型信号：用户说"用 swarm 模式启动"/"蜂群模式"/"所有任务都 spawn 子 Agent 做"/"你只做主控不要自己写代码"。 本 Skill 只做前置校验、写入 execution 字段、声明编排硬约束，随后委派 spec-start 跑既有五阶段流程。 不要用于运行时不支持子 Agent 的环境（退回 spec-start 串行路径）、已有活跃 Spec 的小迭代（用 spec-update）， 也不要用它替代 spec-start —— 流程本体、账本模板、门禁定义仍由 spec-start 唯一承载。
当 spec-start 需要为新 Spec 创建 GitHub Flow 工作分支，spec-update 需要复用/校验当前 Spec 分支，或 spec-end/spec-update 需要提交、推送、创建 PR、合并后清理分支时使用。也用于发版管理：建立或维护 release 分支、打版本 tag、发补丁版本、把修复 cherry-pick 到多条发布线、核对 tag 与分支是否错位、对齐镜像标签与 git tag、清理带版本号的旧分支。不要用于单次查看 git 状态、普通 diff 查询，或用户明确要求不走 GitHub Flow 的临时操作。
| disable-model-invocation | true |
| name | spec-review |
| description | 审查 Spec 执行完成情况，检验实现是否严格按照 Spec 执行，识别未完成项和不符项，在 reviewer/ 下生成审查报告（review.html）。在 spec-execute 完成 executor/summary.html 后、spec-end 归档前使用。`gated` 模式下可选，由 TeamLead 按需启动；`autopilot` 模式下强制介入（自动驾驶下唯一的独立视角）。触发词：审查 Spec、检查实现、Spec Review。 |
进入核心规则前先对齐这张表。它把本 Skill 当成一个有边界的循环单元：明确读什么、能动什么、怎么算完成、什么时候停、什么时候交还给人。
| 项 | 本 Skill 的约定 |
|---|---|
| 输入 | writer/plan.html 或 updater/update-xxx.html、executor/summary.html 或 updater/update-xxx-summary.html、executor/artifacts/、tester/test-plan.html 与 tester/test-report.html、实际代码 |
| 权限 | 只写 reviewer/review.html / update-xxx-review.html（审查结论）；只读代码核对，不修改代码、不修 bug、不归档 |
| 验证 | 按完成度/一致性/额外实现三维核对，每个检查项标注 Spec 位置 + 代码位置（file:line）。审查结论必须落到具体文件与行号，「整体不错」「建议再优化一下」这类无法据以行动的评价不算结论 |
| 停止 | 审查报告定稿且通过该模式对应的确认（gated 用户确认 / autopilot 自门禁通过）即停止；不越界去修复发现的问题（交给 spec-debugger/spec-update） |
| 升级 | 发现核心功能未实现、数据模型严重不符或需重新实现时，在「问题闭环记录」记录并交回 TeamLead 由用户决策 |
| 参考 | 开始审查 → 必读 references/review-rubric.md |
介入方式随模式：gated 模式下 spec-reviewer 可选，由 TeamLead 按需启动；autopilot 模式下 spec-reviewer 强制介入，因为它是自动驾驶下唯一的独立视角，没有它就没有任何人核对「实现是否等于已确认的 plan」。
确认方式随模式：gated 模式下完成审查报告后必须用当前运行环境的确认方式向用户确认；autopilot 模式下由「五类清单逐类给出结论 + 每项结论带 file:line + 结论与 executor/artifacts/ 实际输出一致」替代该确认，三者缺一不可放行。判定标准见 references/review-rubric.md。
gated 模式的确认话术：
确认目标：审查报告已创建完成，审查结果是否准确？
确认选项：
- 审查准确
- 需要调整（请说明问题）
| 场景 | 文件名 |
|---|---|
| 新功能审查 | reviewer/review.html |
| 更新审查 | reviewer/update-001-review.html（编号与 update 对应） |
| 维度 | 检查内容 | 标记 |
|---|---|---|
| 完成度 | Spec 定义的功能是否全部实现（功能点、数据模型、API、测试） | ✅ 已完成 / ❌ 未完成 |
| 一致性 | 实现是否与 Spec 设计一致（接口签名、数据结构、业务逻辑、命名） | ⚠️ 不符 |
| 额外实现 | 是否有 Spec 未定义的额外功能、字段、参数 | ➕ 额外 |
严格模式（默认）：所有功能必须实现、签名完全一致、不允许额外实现
宽松模式（用户指定时使用）：核心功能必须实现、允许小的接口差异和合理的额外实现
| 步骤 | 操作 | 要点 |
|---|---|---|
| 1 | 读取 Spec 文档 | 读取 writer/plan.html 或 updater/update-xxx.html，提取功能点、数据模型、接口定义 |
| 2 | 读取实现与测试产物 | 读取 executor/summary.html 或 updater/update-xxx-summary.html、tester/test-plan.html、tester/test-report.html，并列出 executor/artifacts/ 下的证据文件 |
| 3 | 建立检查清单 | 从 Spec 提取所有需实现的功能点、模型、接口、测试；按 references/review-rubric.md 的五类清单展开 |
| 4 | 检查代码实现 | 根据 summary 文件列表读取实际代码，逐项核对 |
| 5 | 对比分析 | 按三个维度（完成度、一致性、额外实现）识别差异，每项按 blocker / major / minor 定级 |
| 6 | 生成审查报告 | 撰写前先读 html-report skill；在 Spec 目录下创建 reviewer/review.html，模板见 references/review-template.html |
| 7 | 按模式确认 | gated 用当前运行环境的确认方式等待用户确认；autopilot 以自门禁证据替代（判定标准见 references/review-rubric.md） |
问题按严重度分类，判定标准见 references/review-rubric.md：
blocker：会导致数据错误、安全问题或功能不可用，必须修完才能进入收尾major：行为与 plan 不符，或存在明确的失败路径未处理，应在本 Spec 内修minor：可读性、命名、重复代码等，记录为延后项，不阻塞html-report skill，确认最新的骨架、修订规范和禁止事项<span class="rk-ref">src/x.ts:88</span>rk-cal 组件标注：ok 已完成 / risk 未完成或严重不符 / warn 不符项与需关注风险 / key 关键决策<section class="rk-verdict is-pass|is-fail">，与 rk:result（通过/需修复/严重不符）保持一致writer/plan.html、executor/summary.html 用相对链接，分「本报告引用」（rk-links）与「引用本报告」（rk-backlinks）两向；指向运行账本写 ../lead/team-context.md 或 ../lead/team-context.html（按账本实际格式）<head> 内 <meta name="rk:*"> + <link rel="rk-*"> 机器可读，.rk-meta 人可读镜像，两处字段一致，git_branch / base_branch / pr_url 不可丢data-rev 规范：修订号 +1、修订历史表追加一行、正文用 <ins class="rk-ins" data-rev="N"> / <del class="rk-del" data-rev="N"> / <p class="rk-added|rk-removed" data-rev="N"> 标记，永不静默改写确认（gated 用户确认 / autopilot 自门禁）前，先更新当前 Spec 的 lead/team-context.md 共享区：
reviewer/review.html 或 reviewer/update-xxx-review.htmldone / needs-fixspec-reviewerbug / scope / process 等），「发现者」 写 spec-reviewer，owner 建议写 TeamLead 或 spec-debuggergated 模式的用户响应处理：
| 响应 | 含义 | 后续操作 |
|---|---|---|
| "审查准确" | 用户确认 | 审查通过 → 交给 spec-end 归档；需修复 → 等待修复后重新审查 |
| "需要调整" 或 "Other" | 需要修改 | 根据用户反馈调整审查报告 |
| result 值 | 后续操作 |
|---|---|
通过 | 新功能 → 交给 spec-end 归档；更新 → 保留原目录 |
需修复 | 列出问题清单（含 blocker / major 定级）→ 等待修复 → 按 references/review-rubric.md 的限定复审规则重新审查 |
严重不符 | 需要重新实现 |
禁止：
rk-ref）gated 缺用户确认 / autopilot 缺自门禁证据）autopilot 模式下跳过审查阶段推荐：
blocker / major / minor）
SOC 직업 분류 기준