sdlc-review

SDLC 审查技能

独立验证从看板实现流程移交到审查泳道的工作，然后批准、要求修改或升级处理。此技能审查交付成果及其证据；不会接手实现者的工作。

使用时机

符合以下所有条件时，使用此技能：

• 调度器为你分配了一个从 review 泳道领取的任务；
• 实现者提交了 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. 在最终的看板状态转换中记录具体证据。

快速参考

判定	适用情况	最终操作
批准	验收标准和验证均通过	kanban_complete
要求修改	仍存在可修正的实现缺陷	kanban_comment，然后调用 kanban_request_changes
升级处理	需要人工决策或外部前置条件	kanban_block

要求修改的状态转换会将任务退回原实现者。该实现者再次请求审查时若未指定审查者，系统会根据保留的审查者来源信息，将复审分配给同一审查者配置。

审查视角

每一轮都应改变审视工作的方式，而不是重复相同的检查。彼此不相关的视角能发现不同类别的缺陷：冷读交付物能发现被实现者叙述掩盖的设计和正确性问题；实际执行能揭穿无法复现的声明；严格的契约审计则能发现悄然发生的范围偏移。在第 3 轮重复第 1 轮的视角，大多只会再次发现第 1 轮已经找到的问题。

根据任务记录中已有的历史确定当前轮次：统计工作者上下文中“Prior attempts on this task”部分里的 changes_requested 条目数量（在 kanban_show 中也可通过先前运行记录查看）。当前审查轮次等于该数量加一。因此，第 1 轮显示零条 changes_requested 记录；第 2 轮显示一条；依此类推。

轮次	视角	应用方法
1	交付物	在阅读实现者摘要之前，冷读差异或交付物。先形成独立判断，再将其与移交说明进行对比，并调查每一处不一致。
2	执行	检出工作并通过 terminal 实际运行：构建、测试，并亲自验证所报告的行为。通过实证验证移交中的每项声明，而不是重新阅读交付物。
3+	契约	重新阅读原始任务内容和验收标准，然后严格按照它们审计交付物。还要验证此前每一轮 kanban_request_changes 中的所有事项是否都已落实。

“流程”一节中的基础职责仍适用于每一轮；视角决定优先开展哪类检查，以及应重点关注什么。

用不同视角开展临时并行评审

同样的原则也适用于 Kanban 评审流程之外。通过 delegate_task 并行启动多个评审者时，应为每位评审者分配不同的视角——一份只看差异的简报、一份提供完整上下文的简报、一份要求检出并运行项目的简报——而不是给出相同的简报。相同的简报会导致评审结论相关、发现重复；采用不同视角，则能以相同的评审投入覆盖更多缺陷类型。

流程

1. 从持久化任务记录了解情况

调用 kanban_show 并确认：

• 原始任务正文和验收标准；
• 最新的实现摘要和结构化元数据；
• 已更改的文件、提交标识符和测试证据；
• 先前运行中的评论和决策；
• 之前评审轮次的发现。

应将交接内容视为有待验证的主张，而非工作正确无误的证明。

2. 对照交付内容检查请求的行为

将每项验收标准对应到具体的实现或输出证据。在决定是否进行更深入的检查之前，记录遗漏、语义变化和无关范围。

对于代码工作：

1. 使用 read_file 和 search_files 检查已更改的路径及其调用方。
2. 使用 terminal 检查差异，并运行项目现有的专项测试、lint、类型检查或构建命令。
3. 在可行时，复现报告中的失败路径，并至少测试一条常规对照路径。
4. 检查与此次更改相关的错误处理、边界情况、并发边界、数据保留、安全边界和跨平台行为。
5. 确认测试断言的是行为，而不仅仅是对源文本或常量进行快照比对。

对于非代码工作：

1. 检查完整的交付内容，而不只是摘要。
2. 检查正确性、完整性、格式和来源。
3. 如果相关 URL 或外部事实会影响评审结论，请使用适当的原生工具进行验证。

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。
• 已将每项验收标准对应到证据。
• 已检查实际交付物。
• 已运行相关的定向检查；若无法执行，则已记录明确原因。
• 重新审查时，已重新测试之前要求的更改。
• 已考虑无关回归和范围变更。
• 判定恰好使用一个终结操作。
• 摘要包含具体且非机密的证据。
• 审查者未编辑任何实现文件。