{/* This page is auto-generated from the skill's SKILL.md by website/scripts/generate-skill-docs.py. Edit the source SKILL.md, not this page. */}

Sdlc Review

评审看板交接并路由已验证结果。

Skill 元数据

参考：完整 SKILL.md

SDLC Review Skill

独立验证从看板实现回合交到评审泳道的工作，然后批准、请求修改或升级。本 skill 评审交付物及其证据；它不接管实现者的工作。

何时使用

当以下全部成立时使用本 skill：

• 调度器为你派发了一个从 review 泳道认领的任务；
• 实现者提交了 review_requested 交接；
• 任务在完成前需要独立判定。

不要用于单独的下游评审卡。下游卡是带评审导向规格的普通实现工作，经自己的生命周期完成。

前置条件

• 带当前任务和运行标识的看板 worker 上下文。
• 原生看板工具：kanban_show、kanban_comment、kanban_complete、kanban_request_changes 和 kanban_block。
• 当交付物是代码时，经 read_file、search_files 和 terminal 的工作区访问。
• 任务原始规格、验收标准、交接摘要和先前运行历史须可经 kanban_show 获得。

运行方式

本 skill 由评审调度器自动加载。检查文件或选择判定前，先用 kanban_show 开始。

1. 读任务规格和最新 review_requested 交接。
2. 检查实际交付物并运行相关验证。
3. 恰好选择一个判定：批准、请求修改或升级。
4. 在终端看板转换中记录具体证据。

快速参考

请求修改的转换把任务退回原实现者。当该实现者再次请求评审而未点名评审者时，持久化的评审者出处把复审路由回同一评审者 profile。

评审视角

每轮换一种看工作的方式，而非重复同一检查。去相关的视角捕捉不同缺陷类：冷读工件暴露设计和正确性问题（实现者的叙述会把它们框掉），执行暴露无法复现的论断，严格契约审计暴露安静的范围漂移。在第 3 轮重复第 1 轮视角，大多只是重新发现第 1 轮已发现的。

从任务记录已给你的历史判定当前轮次：数 worker 上下文"本任务先前尝试"部分的 changes_requested 条目数（在 kanban_show 中也可见为先前运行）。当前评审轮次即该计数加一。因此第 1 轮显示零个 changes_requested 尝试；第 2 轮一个；依此类推。

流程节中的基线职责每轮仍适用；视角决定你以哪个检查为主、权重最高。

临时评审扇出的视角变化

同一原则适用于看板评审泳道之外。经 delegate_task 派发多个并行评审者时，给每个评审者不同视角——一个仅 diff 简报、一个全上下文简报、一个检出并运行简报——而非相同简报。相同简报产生相关判定和重复发现；变化简报以相同评审投入覆盖更多缺陷类。

流程

1. 从持久任务记录定向

调用 kanban_show，识别：

• 原始任务正文和验收标准；
• 最新实现摘要和结构化元数据；
• 变更文件、commit 标识和测试证据；
• 早先运行的评论和决定；
• 先前评审轮次的发现。

把交接当作待验证的论断，而非工作正确的证明。

2. 比较请求行为与交付行为

把每个验收标准映射到具体实现或输出证据。在决定是否深入检查前，记下遗漏、改变的语义和无关范围。

代码工作：

1. 用 read_file 和 search_files 检查变更路径及其调用方。
2. 用 terminal 检查 diff，运行项目既有的聚焦测试、lint、类型检查或构建命令。
3. 实际可行时演练报告的失败路径和至少一条普通控制路径。
4. 检查与变更相关的错误处理、边界情况、并发边界、数据保留、安全边界和跨平台行为。
5. 确认测试断言行为，而非仅快照源码文本或常量。

非代码工作：

1. 检查完整交付物，而非仅其摘要。
2. 检查正确性、完整性、格式和出处。
3. 当引用 URL 或外部事实影响判定时，用合适的原生工具验证。

3. 选择一个判定

Approve

仅当验收标准满足且证据充分时批准。调用：

kanban_complete(
    summary="Reviewed and approved. <验证了什么>",
    metadata={"review_outcome": "approved", "reviewer_checks": [...]}
)

列入通过的确切检查，以及不阻塞验收的有界保留。

Request changes

用于具体、可纠正的缺陷。先记录可行动发现：

kanban_comment(
    task_id="<current-task-id>",
    body="Changes requested:\n1. <文件或工件 + 缺陷>\n2. <所需修正>",
)

然后把同一任务退回实现者：

kanban_request_changes(
    reason="<所需修正的简明摘要>"
)

说明缺陷在哪、如何复现、为何违反任务，以及什么最小结果能解决它。该转换不使用阻塞复发记账。

Escalate

仅当评审者和实现者在无人工决策或外部前置条件下无法解决问题时升级：

kanban_block(
    reason="escalation: <需要决策或前置条件>"
)

解释被阻塞的决策和继续所需的最小信息。

4. 保持角色分离

担任评审者时不要编辑实现。请求修改，让实现者产出下一候选；然后在下一评审回合独立验证该候选。

常见陷阱

• 橡皮图章： 通过的交接摘要不是独立证据。
• 评审者实现： 编辑交付物掩盖所有权并削弱复审边界。
• 模糊发现："Needs work" 不给实现者可复现的修正目标。
• 仅风格阻断： 行为和仓库标准已满足时，不要为偏好级 nit 请求修改。
• 跳过先前轮次： 复审必须确认所请求修正和先前通过行为的保留。
• 把普通返工用阻塞： 可纠正缺陷属于 kanban_request_changes；kanban_block 留给真正的外部阻塞或人工决策。
• 无证据完成： 每个批准摘要都须点名实际检查的检查或工件。

验证

提交判定前确认：

•  已为当前任务和运行读 kanban_show。
•  每个验收标准已映射到证据。
•  实际交付物已检查。
•  相关聚焦检查已运行，或在无法执行时记录了显式原因。
•  复审时先前请求的修改已重新测试。
•  已考虑无关回归和范围变更。
•  判定恰好使用一个终端动作。
•  摘要含具体、非机密证据。
•  评审者未编辑实现文件。