title: “Sdlc Review — Review Kanban handoffs and route verified outcomes” sidebar_label: “Sdlc Review” description: “Review Kanban handoffs and route verified outcomes”

{/* 本页面由 website/scripts/generate-skill-docs.py 根据技能对应的 SKILL.md 文件自动生成。请直接编辑源文件 SKILL.md，而非此页面。 */}

SDLC 审核

审核看板任务流转，并对验证结果进行判定。

技能元数据

参考：完整 SKILL.md 文件

:::info 以下是当触发该技能时 Hermes 所加载的完整技能定义。技能处于激活状态时，代理将依据此内容执行操作。

::

SDLC 审核技能

独立核查从看板任务流转至审核环节的工作成果，随后可批准、要求修改或上报问题。该技能会审查交付物及其相关证据，但不会替代执行者完成实际工作。

适用场景

在满足以下所有条件时可使用此技能：

• 分配器因您领取了“审核”环节的任务而派发给您；
• 执行者提交了标记为 review_requested 的任务流转请求；
• 该任务在完成前需要独立的判定结果。

请勿将其用于独立的下游审核卡片。下游卡片属于常规的实施工作，仅带有以审核为导向的规范，并会按照自身的生命周期完成处理。

先决条件

• 包含当前任务及运行标识符的看板工作上下文。
• 原生看板工具：kanban_show、kanban_comment、kanban_complete、kanban_request_changes 以及 kanban_block。
• 当交付物为代码时，可通过 read_file、search_files 和 terminal 功能访问工作空间。
• 通过 kanban_show 可获取任务的原始规范、验收标准、交接摘要以及之前的运行历史记录。

运行方式

该技能会由审核调度器自动加载。在查看文件或确定审核结果之前，应先使用 kanban_show。

1. 阅读任务规范及最新的 review_requested 交接信息。
2. 检查实际交付的成果，并执行相应的验证操作。
3. 从“批准”、“要求修改”或“升级处理”中精确选择一种审核结果。
4. 在终端的看板状态变更记录中留存具体证据。

快速参考表

当选择“要求修改”时，任务会退回给最初的实现者。若该实现者再次申请审核但未指定审核人，系统将依据已记录的审核人信息，将重新审核任务分配给同一位审核者。

审核视角

无需重复相同的检查方式，而应针对每一轮的工作采用不同的审视视角。这些相互独立的审查维度能够发现不同类型的缺陷：对代码实体的结构设计进行静态分析，可揭示实现者描述中可能被忽略的正确性问题；对执行过程进行检测，能找出那些无法复现的声称；而严格的契约审计则有助于发现隐性范围的偏差。在第三轮仍使用第一轮的审查方式，大多只是重复第一轮已经发现的问题而已。

您可以从任务记录的历史记录中确定当前所处的轮次：查看工作上下文中的“该任务的先前尝试”部分中所列的changes_requested条目数量（在kanban_show界面中也显示为之前的运行记录）。当前审查轮次即为该数字加一。因此，第一轮的changes_requested条目数为零，第二轮为 one，以此类推。

针对临时审查任务的视角差异设置

在看板审查流程之外也遵循相同原则。当通过 delegate_task 分配多个并行审查人员时，应为每位审查人员提供不同的任务说明——一份仅针对差异的简报、一份包含完整上下文的简报、还有一份要求直接测试运行的简报——而非完全相同的简报。相同的简报会导致一致的判定结果和重复的缺陷发现；而多样化的简报则能在相同的审查投入下覆盖更多类型的缺陷。

流程说明

1. 从持久化任务记录入手

调用 kanban_show 并获取以下信息：

• 原始任务内容及验收标准；
• 最新的实现摘要与结构化元数据；
• 被修改的文件、提交标识以及测试证据；
• 以往轮次中的评论与决策记录；
• 之前审查环节发现的缺陷。

应将任务交接视为需要验证的事项，而非工作已经正确的证明。

2. 对比预期行为与实际实现行为

将每一项验收标准对应到具体的实现代码或输出结果作为证据。在决定是否进行更深入的检查之前，先记录下遗漏的内容、语义上的变化以及无关的范围问题。

对于代码类工作：

1. 使用 read_file 和 search_files 功能来查看发生变更的路径及其调用方。
2. 使用 terminal 功能查看代码差异，并运行项目现有的相关测试、代码检查工具、类型检查或构建命令。
3. 在条件允许的情况下，实际执行报告中的失败路径以及至少一条常规控制路径。
4. 检查与此次变更相关的错误处理机制、边界情况、并发限制、数据完整性、安全边界以及跨平台行为表现。
5. 确保测试能够验证程序的实际行为，而不仅仅是捕获源代码或常量的静态状态。

对于非代码类工作：

1. 需全面审查交付成果，而不仅仅是其概要内容。
2. 检查内容的正确性、完整性、格式规范以及来源可靠性。
3. 若引用的网址或外部信息会影响最终判定结果，需使用相应的本地工具进行验证。

3. 选择一种判定结果

批准

仅当所有验收标准均得到满足且证据充分时才予以批准。操作方式：

kanban_complete(
    summary="Reviewed and approved. <what was verified>",
    metadata={"review_outcome": "approved", "reviewer_checks": [...]}
)

请列出所有已通过的检测项，以及那些不会妨碍任务被接受的有限制性注意事项。

提出修改请求

此功能适用于那些具体且可修复的缺陷。首先需记录下可行的发现结果：

kanban_comment(
    task_id="<current-task-id>",
    body="Changes requested:\n1. <file or artifact + defect>\n2. <required correction>",
)

然后将同一任务反馈给其执行者：

kanban_request_changes(
    reason="<concise summary of the required corrections>"
)

请说明缺陷的当前状态、重现方式、为何不符合任务要求，以及达到何种最低标准才能解决该问题。此流程不采用阻碍因素重复计数机制。

提级处理

仅当审核人员与实现人员无法在没有人工决策或外部前置条件的情况下解决问题时，才可使用提级处理功能：

kanban_block(
    reason="escalation: <decision or prerequisite required>"
)

说明被阻塞的决策原因以及继续推进所需的最少信息。

4. 维护职责分离

在担任审核者时不得直接修改实现代码。应提出修改要求，让实现者生成下一个候选版本；然后在后续的审核中独立验证该候选版本。

常见误区

• 流于形式： 简单的交接总结并不能作为独立的证据。
• 审核者代劳实现： 直接修改交付物会掩盖责任归属，削弱再次审核的边界。
• 描述模糊： “需要改进”这样的表述无法为实施者提供可复现的修正目标。
• 仅因风格问题阻塞： 若功能表现和代码库标准均已符合要求，则不应因细微的风格问题要求修改。
• 跳过前期审核环节： 再次审核必须同时确认所要求的修改内容以及之前已通过功能的稳定性。
• 将普通返工也用阻塞功能处理： 可修复的缺陷应记录在kanban_request_changes中；仅将真正的外部障碍或人为决策用kanban_block标记。
• 无依据便通过审核： 每份审批总结都必须明确列出实际检查过的项或成果。

验证

在提交最终判定之前，务必确认：

• 已读取当前任务的相关信息并调用了 kanban_show 命令。
• 每项验收标准均已对应到相应的证据。
• 实际交付成果已经过检查。
• 已执行了相关的专项检测；若无法执行，则记录了明确的理由。
• 在重新审核时，之前要求过的变更已再次进行测试。
• 已考虑了无关的回归问题及范围变更。
• 最终判定仅使用了一个终端操作命令。
• 摘要中包含了具体且非机密的证据。
• 审核人员未对任何实现文件进行过修改。