reviewing-release-runbook

reviewing-release-runbook — SKILL.md

变体： standard · 使用时机： 将已完成的发布／部署运行手册作为验收门槛进行评判——检查不熟悉该系统的值班工程师能否仅凭运行手册执行部署、确认部署成功并回滚，然后给出 VERDICT: approve|revise 及可执行的改进意见。

概述

此技能是发布运行手册编写／评判技能组合中的评审部分。评审者加载此技能时，持有一份已完成的发布／部署运行手册——即部署或值班工程师遵循的生产环境安全且可验证的上线操作流程（前置条件和签字确认、部署前的 go/no-go 判定、按顺序排列的部署步骤、部署后验证、回滚步骤、升级处理和监控参考信息）。此技能围绕一个问题评判该文档：从未部署过此系统的工程师，能否仅凭这份运行手册执行发布、确认发布成功并安全回滚，且无需内嵌机密，也无需捏造内容？它采用固定的 11 项可执行性 + 安全性检查清单——与发布运行手册作者所遵循的标准一致（作者的第 6 步 + 第 7 步自查），确保编写标准和评审标准不会偏离——然后给出一条可供机器解析的判定，以及作者可在一轮修订中落实的改进意见。它也会将修订版（针对现有运行手册的版本化增量）作为仅针对增量的评审来审查（条件 9）。它是一个验收门槛：不会编写、修复或重写运行手册；它只负责评判并返回改进意见，由编写者进行修订。

此标准与 authoring-release-runbook 技能采用同一来源——即发布运行手册作者所遵循的同一套 11 项可执行性／安全性条件。评审者不会自行另立标准。

何时启用

• 已完成的发布／部署运行手册需要在交付给部署工程师／值班工程师之前作出接受／修订判定。
• 你是运行手册的独立评审者／把关者，需要评审编写者刚完成的运行手册，并持有上游文档（architecture-doc / technical-design / test-plan），以抽查命令和验证步骤。
• 在此前得到 revise 判定后，重新评审修订过的运行手册。

以下情况请勿启用：

• 编写或修复发布运行手册 -> 使用发布运行手册编写技能（它遵循本技能所采用的同一标准）。本技能绝不编写文档。
• 评审 QA 测试计划——测试什么、以何种级别测试、覆盖率如何 -> 使用测试计划评审技能。标准不同；测试计划评审者检查按风险加权的覆盖率和可测试的完成标准。本门槛检查操作可执行性和回滚安全性；运行手册会复用测试计划的退出标准进行部署后验证，而不会重新定义 QA 策略。
• 评审工程设计文档——规格说明、计划、技术设计、RFC 或 ADR -> 使用设计评审技能，根据代码库验证设计主张。该技能把关的是设计；本技能评判的是操作性上线流程。两者是不同的产物，标准也不同。
• 评审 CI/CD 流水线配置——构建、测试和部署自动化 -> 这是另一项独立工作。运行手册会调用流水线；本门槛评判的是其周边流程，而非 YAML。
• 检查模板／章节是否符合要求 -> 这是模板方面的问题。本技能评判的是是否达到质量标准，而非是否包含每个标题。
• 评估实际部署或运行中的服务 -> 本门槛评判的是运行手册文档，而非生产系统。

工作流

第 1 步：以全新、陌生的视角通读整本操作手册，并查阅上游文档

从头到尾阅读操作手册，设想自己是一名值班工程师，从未部署过这个系统，凌晨 3 点第一次接手，而且没有作者的背景说明。你要站在这位陌生操作者的立场把关：只有当某项发现表明操作者无法按文档执行某个步骤、判断成功还是失败，或安全回滚，或者某条命令／主机名是编造的或无法核实的，它才有分量。确定这本操作手册适用的部署类型（单个小型服务，还是包含迁移的多组件系统）——第 2 步的比例校准取决于此。务必加载已提交的上游文档（架构文档中的组件和部署拓扑、技术设计中的发布／迁移方案、测试计划中的退出标准）：它们是你抽查命令、主机名和验证方式的准确性依据。如果未提交某份上游文档，现在就记录下来——第 4 步会将无法运行的追溯信息标记为假设，并据现有材料进行评估；切勿假定无法核实的命令就是正确的。

第 2 步：执行可执行性与安全检查清单——逐项判定

对以下每项条件，判定为通过或存在缺口。只有确实存在明确指出的缺陷时，条件才算不通过——“我会用不同的步骤顺序”不算缺口。对于每个缺口，记录具体步骤／位置及缺失内容（第 4 步会将其转化为可执行的发现）。这 11 项条件是唯一依据的评判标准（与发布操作手册作者在第 6 步和第 7 步的自检中使用的条件相同）；不要自行增加标准。条件 9–11 为有条件适用：条件 9（修订）仅适用于审查现有操作手册的变更；条件 10（有状态变更安全性）仅适用于发布会改变架构／数据的情况；条件 11（沟通）仅适用于会影响用户的部署——否则均为不适用，绝不算作缺口。在发布压力下仍可使用是对整本操作手册进行整体评估的视角（第 3 步的立场），不是编号条件。

1. 陌生工程师也能执行。 每个部署/回滚步骤都具体且可安全复制粘贴——必须是明确标记了 <placeholders> 的真实命令/操作，不能是含糊的描述（“配置服务器”）。重复执行步骤是安全的（幂等：对一次性操作进行保护、使用 IF NOT EXISTS、覆盖而非追加）。如果某个步骤该用命令却只写了描述，或重复执行会破坏状态，则为缺陷。
2. 逐步验证。 每个步骤都说明预期结果，并附有具备明确、可衡量标准的验证检查（延迟/错误率数值、提供服务的版本、健康状态，或 SLO 错误预算消耗速率——而不是“感觉更快了”）。未经验证的步骤不得继续执行。如果某个步骤没有预期结果或可衡量的检查，导致操作人员无法区分成功与无声失败，则为缺陷。（以消耗速率为依据是可接受的可衡量形式，不是必需条件——原始阈值也符合要求。）
3. 包含继续/停止关卡。 部署前检查必须作为部署关卡；任何检查失败都必须明确判定为 NO-GO 并停止流程。如果缺少部署前检查，或虽有检查却没有任何机制能在检查失败时阻止部署，则为缺陷。
4. 完整且安全的回滚，并明确触发条件。 明确列出触发条件（可衡量：错误率/延迟/SLO 错误预算消耗速率/冒烟检查失败）；按相反顺序，为每一项前向变更记录回退方法，并采用与策略匹配的操作方式（蓝绿部署 = 将流量切回；金丝雀/滚动部署 = 将路由设为 0% / 缩容；重建部署 = 重新部署旧制品；特性开关控制 = 关闭开关）；明确指出不可逆的前向变更，并说明相应的前向修复/缓解措施；回滚后重新验证，确认恢复到部署前基线。如果回滚只写“回滚部署”，某项前向变更没有回退方法，触发条件含糊/缺失，回退操作与策略不匹配，不可逆变更没有明确的缓解措施，或回滚后没有重新验证，则为缺陷。影响最大的缺陷类别——回滚不完整会延长故障。（切换开关/自动金丝雀回滚是可接受的操作方式；完整性要求不变。）
5. 部署后验证复用具体检查。 部署后冒烟检查必须包含具备可衡量成功标准的具体检查；如果已提交测试计划，则复用其中的验收标准；并在明确说明的观察期内进行监测。如果缺少部署后验证、将其定义为“看起来没问题”，或忽略已提交测试计划中的验收标准，则为缺陷。
6. 具体的升级处理流程和监控信息。 提供真实的值班/升级处理路径（通知谁、严重性分级、各级别的响应时限），以及真实的监控/可观测性入口（通过链接提供仪表板/告警/日志，且每项都说明“健康状态应是什么样”）——不能使用占位内容。如果升级处理流程或监控信息只是占位内容（“通知值班人员”“查看仪表板”），没有具体联系人、链接或健康基线，则为缺陷。
7. 不得内嵌密钥。 操作手册中不得出现真实令牌/密码/密钥/连接字符串；应通过其存储位置/保险库/环境变量名称引用密钥。缺陷——操作手册中任何位置嵌入的真实密钥都属于问题；必须引用其存储位置。（密钥绝不能存放在已提交/已部署/已记录日志的文件中。）
8. 不得捏造；命令/主机准确无误。 每条命令、每个主机和端点都必须可追溯到已提交的上游资料（架构文档中的组件、技术设计中的发布流程、测试计划中的验收标准），或在操作手册中明确标记为假设。对照已提交的上游资料抽查命令/主机/端点；无法验证的内容必须标记出来，不能假定其正确。如果为填充模板而捏造命令/主机/端点并将其作为事实呈现，或与已提交的上游资料相矛盾，则为缺陷。
9. 按差异范围修订（仅适用于针对现有操作手册审查变更的情况——这是输入信号；从零开始首次构建时不适用）。审查应限于差异范围，而非全面重新审查：差异属于审查范围（修改而非重写）；针对变更原因进行处理（重新推导上游变更，或将事故后的经验转化为回滚触发条件/验证关卡/修正后的步骤）；变更/新增步骤满足适用的约束条件（1/2/4 + 7/8）；修订内容说明了重新验证情况——从头到尾重新检查流程，确认下游前置条件未被破坏，并刷新“上次验证”标记，或明确标记重新验证尚待完成（不强制重新进行完整演练——演练绝不是关卡）；并保留变更历史（提升操作手册版本号 + 变更日志注明触发原因 + 标明被取代的先前版本）。如果修订重新生成了整份操作手册、编辑导致下游步骤失效、新增了没有回退方法的前向变更（或引入密钥/捏造内容）、完全忽略重新验证，或没有变更历史，则为缺陷。干净利落的差异修订应通过（不能因“没有重新审查所有内容”或“没有重新执行演练”而错误要求修改）。
10. 有状态变更安全性（按实际情况适用——仅当发布会更改架构或数据时适用；否则不适用，不构成缺陷）。架构/数据的前向变更必须可逆/向后兼容（采用扩展并收缩/并行变更序列——并行添加、迁移、稍后收缩），或为不可逆变更指定明确的恢复路径（向前修复/隔离/从备份恢复），不能依赖会丢失数据的虚构降级迁移。依据结果判断，不强制要求采用特定模式名称。如果破坏性架构变更发布时既没有向后兼容的变更顺序，也没有明确的恢复路径（例如 DROP/破坏性转换的“回滚”是无法恢复数据的降级迁移），则为缺陷。（这是对条件 4 的补充：灾难性的迁移缺陷可能同时归入两项——这是有意强调，修复一次即可。）
11. 沟通/维护窗口（按实际情况适用——仅当部署会影响用户时适用；内部部署/零用户影响的部署不适用，不构成缺陷，审查者无需提出意见）。影响用户的部署必须说明沟通/维护窗口计划（提前通知/在状态页公布维护窗口/恢复后通知，并为每个渠道指定负责人）。依据结果判断。仅当明显会影响用户的部署（停机/面向客户的变更）完全没有沟通计划时，才构成缺陷。 比例原则。“一位不熟悉项目的工程师能否据此部署、验证并回滚”，应与部署规模相称。小型单服务发布可以合理地省略不需要的部分——如果只有一个实例，就不需要多批次发布；如果团队规模小，升级路径就可以简化；如果影响范围很小，监控链接就可以少一些；如果没有任何变更会修改架构，就不需要 cond-10 有状态安全部分；如果没有用户，就不需要 cond-11 沟通计划。这属于恰当的规模控制，并非遗漏。评估运维人员的执行与恢复能力，而不是字数或章节数。满足所有适用条件的精简完整操作手册，应予通过。不要仅因内容简短就认定存在缺口。（条件 4、7 和 8 在任何规模下都适用：每项前向变更都必须有回退方案，不得内嵌机密，不得捏造内容。条件 9、10、11 则视情况适用——不适用时标记为 n/a。）

步骤 3：确定结论

• approve — 所有适用条件均通过（不适用的条件 9/10/11 应标记为 n/a，而不是缺口），且操作手册在发布压力下仍可用（整体判断标准——凌晨 3 点，无需作者协助也能照着执行）。不熟悉项目的工程师能按照操作手册执行部署、确认部署成功并安全回滚；没有内嵌机密，也没有捏造内容。对于amend，如果审查范围仅限于变更内容，且审查结果合格（条件 9），则应通过——不要重新审查未变更的操作手册。即使你能想到风格方面的改进，也应予通过；标准是可执行性和安全性，而非完美，更不是面面俱到。
• revise — 一个或多个适用条件存在明确缺口，导致无法安全执行（例如：部署步骤没有验证方法、前向变更没有回退方案、内嵌机密、捏造或无法验证的命令、缺少继续/停止关卡、升级路径仅为占位内容、破坏性架构变更没有恢复路径、amend 破坏了下游前置条件等）。

不要为了体现审查工作量或索要锦上添花的内容而要求修改。条件要么满足，要么不满足。对于不适用的条件，不要仅因操作手册内容精简而要求修改。

步骤 4：给出判定结果 + 可执行的发现

将判定结果作为单独一行输出——必须是字面文本 VERDICT: approve 或 VERDICT: revise，单独占一行，不得添加代码围栏、引号或其他字词（此处的围栏仅作示例）：

VERDICT: approve

然后在后续行列出发现。判定为 revise 时，每项发现都必须可执行——指出未通过的条件、确切步骤／位置以及修复方法，让作者一次性解决问题。判定为 approve 时，可选择列出不阻塞的备注；不得让备注暗示必须修改。

如果未提供上游资料，请在发现中明确说明这是一个假设（例如：“未提供 architecture-doc——命令／主机准确性（条件 8）仅根据操作手册内部一致性进行抽查；请提供上游资料，以便进行完整追溯”），并根据现有内容评判其他条件。不得对无法运行验证的准确性检查视而不见，也绝不能假定未经验证的命令正确。

一项好的发现会指出差距和修复方法：

revise — 完整且安全的回滚（条件 4），“步骤 5：运行架构迁移”：此正向变更没有记录回退方法，也没有回滚触发条件。修复：添加反向迁移步骤（或者，如果无法逆转，则明确说明这一点，并提供正向修复／从备份恢复的缓解方案），以及可衡量的触发条件（例如，在 10 分钟观察期内错误率 > 2% 时触发回滚）。

revise — 不内嵌机密（条件 7），“步骤 2：部署”：此步骤内嵌了包含密码的有效数据库连接字符串。修复：使用密钥存储库／环境变量名称引用机密（例如，引用来自密钥库的 $DATABASE_URL）；只显示是否存在，绝不显示其值——真实机密不得出现在操作手册中。

revise — 每个步骤都有验证（条件 2），“步骤 4：将流量切到新环境”：没有预期结果或检查。修复：说明预期输出（例如，绿色环境承载 100% 流量，/healthz 返回 HTTP 200），并提供操作员在继续下一步之前要运行的可衡量检查。

revise — 有状态变更安全性（条件 10），“步骤 3.2：ALTER TABLE orders DROP COLUMN legacy_total”：这是破坏性且不可逆的变更，但回滚写的是“运行降级迁移”——删除列的数据无法通过降级迁移恢复。修复：采用扩展－收缩的发布顺序（本次发布停止写入该列，后续发布再删除），或者在回滚方案中列出真实的恢复路径（从备份 <location> 恢复／正向修复）。

revise — 仅限差异范围的修订（条件 9），变更请求重命名了步骤 3.1 中的部署目标环境，但步骤 4.2 的验证仍对旧主机执行 curl：此编辑破坏了后续步骤的前置条件。修复：从头到尾重新验证流程——将步骤 4.2（以及之后的任何步骤）更新为新主机，然后提升操作手册版本并在变更日志中记录触发原因。

不好的发现含糊不清且不可执行：

回滚部分可以写得更全面一些。（哪个正向变更？什么触发条件？如何修复？）

规则

硬性规则（绝不可违反）：

• 恰好输出一行判定：VERDICT: approve 或 VERDICT: revise——该字面标记必须单独占一行，除此之外不得包含任何内容。下游工具会解析它（判定解析契约）。不得使用其他判定用语。
• 评审，不撰写。 返回问题；不要改写、修复或补全操作手册。由编写者负责修改。
• 统一评审标准。 按照第 2 步中的 11 项条件进行评审——这也是作者撰写时遵循的标准（第 6 步和第 7 步的自查标准）。不要另加条件，也不要套用更严格的个人标准。
• 条件性条件不适用时绝不判为不通过。 条件 9（修订）仅适用于针对现有操作手册的变更；条件 10（有状态安全性）仅适用于架构或数据变更；条件 11（沟通）仅适用于会影响用户的部署。不适用时标记为不适用，而非缺项——绝不要因为精简的操作手册未涵盖未触发的条件而要求修改。
• 修订仅评审差异部分。 如果收到的是针对现有操作手册的变更，应评审差异部分（条件 9）——是否属于范围内、是否响应触发条件、是否说明端到端重新验证，以及是否记录变更历史，而非评审未变更的部分。不要强制要求重新演练；演练是辅助措施，不是门槛。
• 回滚完整性是关键维度。 每项正向变更都必须有对应的撤销步骤，按相反顺序执行，并有可衡量的触发条件和恢复至基线的重新验证；不可逆变更必须明确说明并提供缓解措施。回滚不完整（条件 4）是影响最大的缺陷——这可能导致长时间中断。
• 内联密钥始终属于问题。 操作手册中的任何位置若包含真实令牌、密码、密钥或连接字符串，都不符合条件 7——没有例外，无论有多方便。必须引用其存储位置、密钥保管库或环境变量名称。
• 对照所提供的上游资料抽查命令；标记无法验证的内容。 将每条命令、每个主机和每个端点追溯到上游资料（架构文档、技术设计或测试计划），或明确标注的假设。无法验证的命令应予以标记（条件 8），绝不能默认其正确。虚构或与上游资料矛盾的命令属于缺项。
• 不得误判为需修改。 符合所有适用条件的操作手册应予以批准，即使是针对小型部署的精简手册也一样。只要涵盖了关键操作步骤，按比例精简就不构成缺陷。只有存在明确、具体的问题时才要求修改。
• 不得误判为批准。 不要为了表示认同而忽略真正的缺项。阻断性缺项应判为 revise。
• 没有验证步骤的部署步骤属于缺项。 如果某个步骤没有预期结果或可衡量的检查项，就不符合条件 2——操作人员无法判断是成功还是悄无声息地失败。
• 捏造内容属于缺项，而非有依据。 将虚构的命令、主机、端点或阈值作为事实呈现，不符合条件 8——应将真正的问题标记为假设，而非用未经证实的内容掩盖。
• 缺少上游资料时应予以标记，不得默默放行。 如果未提供某份上游资料，应明确指出这是一个假设，并说明命令或主机的准确性（条件 8）无法得到完整抽查；其余部分则根据现有资料评审。
• 根据操作手册所依据的上游资料进行评审。 按照其 depends_on 集合（项目实际生成的上游资料）进行评估。未生成的上游资料绝不能成为要求修改的理由——不要臆想项目没有生成的文档。但如果操作手册忽略了已生成且本应参考的上游资料（例如，未沿用所提供测试计划中的退出标准来进行部署后验证），则应作为合理问题提出。
• 每条修改意见都必须可执行——指出未通过的条件、具体位置和明确的修复措施。不要提出含糊的问题。

偏好（可酌情调整）：

• 按严重程度排列问题——优先列出回滚完整性和内联密钥问题，再列出其他问题。
• 在每条问题中注明条件编号或名称，方便作者对照评审标准。
• 批准意见应少而精，并明确说明其不构成阻断。

易错点

• 因完整性而非可执行性批准。 每个章节都可以齐全，但操作手册仍可能无法执行（该写命令的地方只有说明文字，步骤没有验证，回滚只写了“回滚”）。评判标准应是陌生的工程师能否据此部署并恢复，而不是模板是否填满。
• 看似完整的不完整回滚。 回滚章节可能看起来很详尽，但某一项前向变更（架构迁移、功能标志、DNS 切换）没有对应的撤销操作，而这恰恰是会延长服务中断的变更。追踪部署中的每一项前向变更，确认都有匹配的撤销操作（条件 4）；没有撤销操作的前向变更，是影响最大、最容易漏掉的缺陷。
• 与部署策略不匹配的回滚。 蓝绿部署通过切回流量来回滚；重新创建部署通过重新部署旧制品来回滚；金丝雀部署通过将流量路由比例设为 0% 来回滚。针对错误部署策略编写的回滚流程，在事故发生时不会生效。检查回滚是否与操作手册中的实际部署策略相匹配。
• 明目张胆却不易察觉的内联密钥。 步骤中粘贴的有效令牌、密码或连接字符串看起来像是可用的命令，却会让密钥泄露到操作手册存放的每个位置。任何真实凭据值都属于问题（条件 7）——必须引用其存储位置；扫描命令片段，检查其中是否嵌入了凭据值，而不只是查看“密钥”章节。
• 捏造的主机名／命令。 为了让操作手册显得完整而编造的主机名或 CLI 标志，会导致操作手册在首次使用时就失败。对照提交的上游资料抽查命令／主机名（条件 8）；没有上游依据且未标注为假设的内容，不是覆盖充分，而是缺陷。
• 带有虚构 down 迁移的不可逆迁移（条件 10）。 DROP／破坏性转换的“回滚”若只是无法恢复已删除数据的 down 迁移，看似完整，实则不然——数据已经丢失。检查破坏性架构变更是否采用扩展-收缩式顺序，或明确列出真实的恢复路径（从备份恢复／向前修复）。但这要按比例判断——如果没有任何操作会更改架构，则不适用。
• 把修订请求重新审查成完整评审（条件 9）。 对变更请求，应评判差异内容、端到端一致性（编辑是否破坏了后续前提条件）以及变更历史，而不是整个未修改的操作手册，也不应强制要求重新演练。重新评审所有内容，或在重新验证标记为待处理时，因缺少新的“上次验证时间”而要求修改，是修订评审中最常见的错误。
• 要求内部部署提供沟通方案（条件 11）。 沟通方案应与用户影响程度相称；对于零用户的内部部署，因缺少状态页面方案而要求修改属于误判。
• 缺少上游资料时的盲点。 如果没有提交上游资料，就无法全面抽查命令准确性——不要因此默认批准。应将其标记为假设（条件 8 部分无法执行），并评判其余内容；绝不能假定无法验证的命令是正确的。
• 系统性过度标记（误判为需修改）。 受邀查找问题的评审者——尤其是同时忍不住提出修复建议的人——容易矫枉过正，把合理的操作手册判为有缺陷。请以评审标准为准：只有明确指出具体且真实的缺陷，才算存在缺口；步骤顺序或命令风格与自己不同，不算缺陷。看似合理的小问题是此处最常见的评审错误。
• 把符合比例的操作手册误判为需修改。 小型单服务部署本就应该简洁——没有分批发布、升级路径简单、监控链接很少。这是恰当的规模，而不是规格不足。因内容简短而凭空制造缺口，会导致本可避免的反复修改；请根据范例校准判断（条件 4、7 和 8 仍然适用：每项前向变更都必须有撤销操作，不得内联密钥，不得捏造内容）。
• 将此评审与测试计划或设计评审门槛混淆。 此处评判的是运营上线操作手册。测试计划评审考察 QA 覆盖范围／可测试性策略；设计评审则依据代码库审核工程设计文档。不要用 QA 覆盖或设计文档的标准来评判部署流程。
• 结论标记漂移。 “Approved”“LGTM”“needs work”或埋在段落中的结论都无法解析。请单独一行输出字面内容 VERDICT: approve|revise。

反模式

• 盖章式批准。 为了避免来回修改而草草浏览后批准——设置这道关卡，是为了发现陌生工程师无法执行或恢复的运行手册；放过没有回退方案的正向变更、内联的密钥，或没有验证步骤的操作，最终会导致部署失败或长时间中断。
• 跳过回滚追踪。 “部署步骤看起来没问题，我批准了”——不逐一追踪每项正向变更对应的回退方案，就会漏掉影响最大的缺陷类别（条件 4）。回滚不完整，正是这道关卡最需要发现的问题。
• 跳过上游抽查。 “这些命令看起来合理，我批准了”——不对照已提交的上游内容进行抽查，就会放过捏造或已过时的命令（条件 8）。既然已提交上游内容，却仍孤立地审查运行手册，这种捷径是本关卡所禁止的。
• 吹毛求疵式要求修改。 把步骤顺序偏好、措辞偏好或包装成缺口的锦上添花要求当作阻塞问题。只有真正妨碍可执行性或安全性的情况才要求修改。
• 悄悄改写。 “直接修好回滚步骤更省事”——在审查过程中代为编写，会破坏产出与评判的分离，也剥夺作者了解问题的机会。
• 凭空增加条件。 添加评审标准中没有的私人要求（“还应该附上负载测试附录”），会使评审标准偏离产出标准，并导致不必要的修改要求。只评判这十一个条件——技术辅助措施（扩展-收缩分阶段实施、金丝雀分析、功能标志、演练运行、错误预算消耗速率数值）应根据结果评判，绝不能按是否明确采用某项措施来要求。
• 对有条件适用的条件误判为需修改。 对无状态部署指出“没有迁移安全性章节”，对内部工具指出“没有沟通计划”，或对修订稿指出“没有重新运行演练”——这些都不适用，不是缺口。条件 9/10/11 在不适用时不予评判。
• 追求面面俱到。 对不需要复杂流程的精简单服务部署，强求多批次发布、完整的 SRE 升级处理树或冗长的监控目录。标准是操作人员能否执行并恢复，而不是运行手册能否尽可能庞大。
• 含糊的判定。 “基本批准，但是……”或给出两行判定。只能有一个决定，且只能有一个判定词。

输出

针对一份发布／部署运行手册给出单一审查结果：

• 一行判定 — VERDICT: approve 或 VERDICT: revise，逐字照写，单独占一行。
• 发现的问题 — 若判定为 revise，每个阻塞缺口各列一项可执行的发现（未通过的条件 + 位置 + 具体修复方法）；若判定为 approve，可选列出非阻塞备注。

当前待审查的运行手册是文本形式——包含编号流程步骤、围栏代码块中的命令／检查片段、预期输出块、验证／检查表，以及指向仪表盘／监控项的链接（由本地文档后端通过 Markdown 提供）；审查方法和标准与媒介无关（未来改用渲染式运维控制台只会改变媒介，不会改变评判内容）。抽象的使用方是负责协调产出->审查循环的系统：approve 表示接受运行手册，供执行部署的工程师／值班工程师使用；revise 则将发现的问题返回给产出方，以便进行范围受限的修订。

相关内容

• release-runbook-authoring 技能（authoring-release-runbook）——这对技能中的编写部分；它会编写满足本技能评审标准的同一套 11 项条件可执行性与安全性要求（第 6 步和第 7 步自检）。将两者配对可以统一标准，避免编写与评审的要求出现偏差。
• test-plan-review 技能——QA 测试计划的把关环节（覆盖范围、级别、可测试的完成标准）。这是不同的文档，有不同的标准；runbook 会复用测试计划中的退出标准进行部署后验证（条件 5），但此把关环节评审的是操作流程，而非 QA 策略。
• design-review 技能——工程设计文档（规格说明、计划、技术设计、RFC、ADR）的把关环节，用于根据代码库核验设计主张。这是不同的把关环节，评审不同的产物；不适用于操作性上线 runbook。
• 上游架构文档 + 技术设计 + 测试计划（如已提供）——本把关环节会抽查 runbook 中的命令和验证方式是否与之相符（条件 8 / 条件 5），这些文档说明可部署组件、发布流程和退出标准。
• release-runbook 模板 / content-template 工具——负责章节结构；本技能评判的是是否达到质量标准，而非结构是否合规。

渐进式披露

• references/executability-safety-bar.md——深入说明这套 11 项条件标准：各条件的通过/缺项信号和示例评审结果，包含深化后的条件（条件 2 的燃尽率、条件 4 的调节手段 + 策略匹配）和新增条件（条件 9 的修订、条件 10 的有状态变更安全性及其按比例简化、条件 11 的沟通及其按比例简化）。在校准边界案例的评审结论时加载。
• references/sources.md——评审方法的研究来源说明（统一来源的可执行性/安全性质量标准，以及各项条件背后的 SRE / 运维依据——验证关卡、回滚触发条件、扩展-收缩 + 前向修复、燃尽率、发布策略机制、功能标记、通过引用管理密钥）。仅在审查指导内容的来源时加载。

正文篇幅限制

• description <= 1,024 个字符（agentskills.io 限制）。Claude 会在列表中将 description + when_to_use 合计截断至 1,536 个字符。
• 正文 <= 约 500 行 / 5,000 个 token——每轮都会保留在上下文中。
• 单个参考文件：超过 10k 个 token 时警告，超过 25k 时错误。参考文件总量：超过 25k 个 token 时警告，超过 50k 时错误。