菜单
Use when reviewing code, reviewing a task report, performing code review, or when user says 审查, review this, code review, 代码审查. Defines the trust-but-verify gate with 10 quality gates and 4-step review cycle.
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/Ezio0/agent-engineering-workflow --skill review-gate命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
Automate a Manifest-bound delivery across Positioning, PRD, Spec, Impact, Plan, Test Plan, implementation, verification, and Candidate review by coordinating independent author/reviewer loops inside a human-approved Authority Envelope. Use when a user asks to execute a feature end to end, reduce repeated document confirmations, automate workflow gates, use graph engineering for delivery, or continue automatically while escalating only scope choices, authority expansion, non-convergence, and irreversible actions.
Write implementation plans for features that have passed a human or independent artifact-review Spec Gate. Defines Phase breakdown, task sizing (XS/S/M), dependency graph, and estimated vs actual time tracking. Trigger: after a valid Spec Gate, before Test Plan.
Use when writing a PRD, starting a new feature that needs requirements, or when user says 写PRD, 产品需求, feature requirements, 需求文档. Defines the 13-section PRD structure with mandatory observability requirements.
基于 SOC 职业分类
正在显示 SKILL.md
| name | review-gate |
| description | Use when reviewing code, reviewing a task report, performing code review, or when user says 审查, review this, code review, 代码审查. Defines the trust-but-verify gate with 10 quality gates and 4-step review cycle. |
| version | 1.0.0 |
| author | human owner Agent Workflow |
| license | MIT |
| metadata | {"hermes":{"tags":["review","quality","gate","code-review","workflow"],"related_skills":["global-launch-review","pre-delivery-review"]}} |
这是 Stage 07。它是实施（Stage 6）和提交（Stage 8）之间的信任但验证关卡。
Review 的职责很窄、很明确：(1) 验证 Task Report 结构完整；(2) 验证报告中的证据真实；(3) 验证范围匹配声明；(4) 生成 Commit 阶段可执行的 Review Decision。
Review 不做什么：不重跑测试、不重读代码每一行、不评审 Spec / Plan、不协商范围变更、不凭直觉批准。重跑是浪费工作；重读让 Reviewer 成瓶颈；协商范围是 Plan 修订；凭直觉批准和"盖章"无法区分。
强制 3 个硬关卡（G1/G2/G3）+ 10 个质量门（QG-1 ~ QG-10）+ 4 步循环（读报告 → 核范围 → 验证据 → 决策）。任何 QG 失败都不允许 APPROVED。任何 VIOLATION 偏差升级为 BLOCKED。
启动本 skill 的典型场景：
不要使用的场景：
3 条全部成立 Review 才能开始。任何一条失败，把 Task Report 退回 Stage 6 并说明原因 —— 不要即兴发挥。
文件在 docs/06-implementation/reports/<project>_task_<T-NNN>_v1.0_<date>.{en,zh}.md，文件名遵循命名规范。
为什么需要这条？没有 Task Report 的 review 是空对空 —— 你在 review 什么？没有结构化产出，证据无处附着，决策无法追溯。
第一个非 frontmatter 行是 > **状态**：已完成 | 失败 | 阻塞 | 部分完成，4 个有效值之一。
Status header 决定 Review 是否相关 —— 一个 阻塞 状态的 task 不需要验证据，只需要确认停止条件已披露。先读 Status 让 Review 走对方向。
做 Review 的 session / 人不是产出本 Task Report 的那个。自我评审按定义总是通过 —— 它和"我自己提交自己的工作，没第二双眼睛"是同一个反模式。
G3 是日常实践中最常违反的关卡。"我刚写的，让我快速 review 一下"必须拒绝。你写了代码，就不能是 Reviewer。停止，移交。
读报告 → 核范围 → 验证据 → 决策
| 步骤 | 时间盒 | 输出 |
|---|---|---|
| 读报告 | ≤ 5 分钟 | 先读 Status header；全报告扫一遍；§11 预填已记录 |
| 核范围 | ≤ 10 分钟 | §2 AC 表 + §4 文件表对照 Stage 5 Target Files 交叉核对 |
| 验证据 | ≤ 15 分钟 | §7 测试输出抽查（行是真实的）；§6 覆盖率数字验证；§3 SHA 用 git log 确认 |
| 决策 | ≤ 5 分钟 | 生成 Review Decision：APPROVED / CHANGES REQUESTED / BLOCKED |
总计每个 task 约 35 分钟。比重新实施快；比"盖章"慢。这个时间盒是设计目标，不是建议。
每个 QG 必须显式验证（PASS / FAIL），不允许"未标注"。"未标注"意味着"Reviewer 没检查"，不是"Reviewer 查了且没问题"。
§2 表里每条 AC 有 ✅ / ⚠️ / ❌。Reviewer 对每条标准对照证据指针读。每个 ⚠️ 有 follow-up task ID；每个 ❌ 有阻塞说明。
§4 文件表与 Stage 5 Target Files 声明交叉核对 —— 每个文件 ✅。任何不在 Target Files 的文件必须有 §8 偏差条目且 severity 诚实分类。无 VIOLATION（否则 BLOCKED）。
§7 输出逐字，不是意译；行数 ≥ 50（或更小套件时完整输出）；含退出码；末尾含覆盖率报告；如有失败，含失败输出 + traceback。
拒绝如果：输出是意译（"全部 24 个测试通过"）；< 50 行但明显有更多测试；可疑地干净（无 warning、无耗时、无平台信息）；声称"100% 覆盖率"但无按文件分解。
§6 覆盖率变化显示单元 ≥ 80%，集成 100%，E2E 100%（或按 Test Plan §1 覆盖）。三层拆分在场；按文件分解在场（无模糊的"100%"）；任何未达标层级有 follow-up task ID。
§3 SHA 是真 SHA（40 个十六进制字符），git log --oneline <SHA> 能找到 commit；Commit message 匹配 Stage 8 格式；Commit 作者是 human owner（或 human owner 指定的人），不是 agent；git show --stat <SHA> 文件列表匹配 Task Report §4。
Status 与正文匹配 —— 如果 Status 是"已完成"但任何 AC ❌，header 在撒谎。撒谎的 Status header 比错误状态更糟，因为它表明 agent 想藏东西。当软违规处理。
§6 无 @skip / xfail / it.skip 无理由加入；无测试被删除（通过 git diff 对照前版 Task Report 验证）；任何跳过有理由 + follow-up task ID；任何删除的测试在 §8 披露并标 severity。
§5 Spec 章节全部存在于 Stage 2 Spec —— Reviewer 通过打开 Stage 2 验证。无编造的章节引用。如章节不存在：VIOLATION，BLOCKED。
§8 含每条偏差，每条有 severity（TRIVIAL / ADJUSTMENT / SCOPE-CREEP / VIOLATION）；每个 SCOPE-CREEP 有 Plan 引用证明合理；每个 VIOLATION 是 BLOCKED 候选。Severity 分类通过"这真的算 TRIVIAL 吗？"测试。
§9 有项或"无" —— 不是省略。项有 follow-up task ID 或升级标记。
Stage 6 §8 列了 4 个 severity 等级。Reviewer 的工作是确认 severity 诚实分类并相应反应。
| Severity | 定义 | Reviewer 动作 |
|---|---|---|
| 琐碎（TRIVIAL） | Typo 修复、docstring 改进、注释澄清 | 批准；在 Review Decision §3 标注 |
| 调整（ADJUSTMENT） | 文件路径不同但意图一致（如重构移了代码） | 批准；验证意图保留；在 §3 标注 |
| 范围蔓延（SCOPE-CREEP） | 加了未要求的功能 | CHANGES REQUESTED，除非 §8 显式带 Plan 引用批准 |
| 违规（VIOLATION） | 修改 Target Files 之外的文件，或违反停止条件 | BLOCKED —— 退回 Stage 6；不批准 |
Reviewer 容易被诱惑把 SCOPE-CREEP / VIOLATION 降级到 TRIVIAL 避免 CHANGES REQUESTED 的摩擦。测试：
不带任何其他上下文，一个 Task Report 的读者能否仅从 Plan / Spec / Test Plan 理解为什么做了这个改动？
YES → TRIVIAL 或 ADJUSTMENT NO → SCOPE-CREEP 或 VIOLATION
答案 NO 就不批准。改动需要 Plan 级别的理由。
每次 Review 产出正好一个决策。无"带保留批准" —— 那要么是 APPROVED + §3 标注，要么是 CHANGES REQUESTED。
全部 10 个 QG 通过，全部偏差是 TRIVIAL 或 ADJUSTMENT（或无），证据真实。交给 Stage 8（Commit）。
任何 QG 失败，或任何偏差是 SCOPE-CREEP，或证据无法验证。把 Task Report 退回 Stage 6，带具体 §4 action items 清单。每项引用具体 QG 或 §8 偏差，每项有可验证接受条件。
任何 VIOLATION severity 偏差，或停止条件被命中但未披露，或检测到自我评审（G3 失败），或实施与 Plan / Spec 根本性错位。Task 无法继续，除非上游文档修订。停止 Review 循环，升级 human owner。
修订后的 Task Report 必须：(1) 有新版本后缀（如 v1.1）—— 绝不覆盖旧的；(2) 有 ## Revision History 章节列出相对被拒版本改了啥；(3) 如做了新 commit 有新 SHA。历史保留让原失败可审计。
症状：APPROVED 但 Review Decision 没引用具体 QG。
真实原因：无证据的批准和盖章无法区分。Review Decision 模板强制每个裁决引用至少一个 QG；如果你填不出 §4 的 QG 引用，你就没 review。最阴险的反模式 —— 感觉有产出，实际和"没 review"一样。
症状：QG-3 标 PASS 但没抽查格式。
真实原因：测试输出可被编造、意译、截断。必须抽查 —— 首行、末行、一行中段是真实 pytest/jest 等的输出。看格式、行数、退出码、覆盖率报告完整性。
症状：Reviewer 在报告层之外读代码细节，逐行评判实现。
真实原因：Reviewer 成瓶颈，违背阶段分离。Review 报告，不是代码；代码关切标为 §3 非阻塞观察，建 follow-up task。深度代码评审是独立的、ad-hoc 流程，不在 Stage 7。
症状：把命名、注释、结构偏好塞进 §4 action items。
真实原因：风格是 Stage 10 的工作，不是 Review 工作。§3（Comments）非绑定标注；建 follow-up task。把 Review 变成风格瓶颈违背分阶段初衷。
症状：Reviewer 就是写代码的那个 agent。
真实原因：自我评审总通过，G3 失败。如果你写了代码，移交；G3 就是防这个。没有"嗯，我还是仔细 review 了"例外 —— 整个 review 无效，必须重新指派。
症状：直接验证据，没做 §4 文件表与 Target Files 的交叉核对。
真实原因：Reviewer 倾向聚焦代码，跳过文件列表。不要跳过。范围是实践中最常失败的检查。"既然来了，顺手修这个 typo" 是 VIOLATION —— 永远拒绝。Target Files 规则对所有被跟踪文件适用，无例外（CHANGELOG、测试 fixture 都算）。
症状：§8 偏差标 TRIVIAL，但改动需要在 Plan 才能理解。
真实原因：Reviewer 被诱惑避免 CHANGES REQUESTED 摩擦。跑"这真的算 TRIVIAL 吗？"测试。答案 NO 就 CHANGES REQUESTED，不要降级。
每次 Review session 跑一份新的（不是每个项目）。
docs/06-implementation/reports/...Reviewer 签字：___________________ 日期：___________________
签字后：APPROVED → 进入 Stage 8（Commit）；CHANGES REQUESTED → 退回 Stage 6；BLOCKED → 升级 human owner + 上游修订。