Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →Use when requesting code review for completed work or when receiving code review feedback
| Test case | Without → With | Effect | Δ tokens | Δ turns |
|---|---|---|---|---|
| case-09 | ✗→✓ | ▲ Improved | 178% | 0% |
| case-02 | ✗→✓ | ▲ Improved | 80% | 0% |
| case-03 | ✗→✓ | ▲ Improved | 103% | 0% |
| case-04 | ✗→✓ | ▲ Improved | 140% | 0% |
| case-07 | ✗→✓ | ▲ Improved | 95% | 0% |
在软件开发流程中自动执行代码审查：完成任务后自动发起审查，收到反馈后技术严谨地处理。
核心原则： 审查是流程的自动环节，不是可选步骤。实现前先验证，不表演性同意。
强制触发点：
开发流程集成：
1. 获取 git SHAs：
bashBASE_SHA=$(git rev-parse HEAD~1) # 或 origin/main HEAD_SHA=$(git rev-parse HEAD)
2. 分派代码审查者子 Agent：
使用 Task 工具配合 sw-code-review 类型，填写 ./code-reviewer.md 模板
占位符：
{WHAT_WAS_IMPLEMENTED} - 你刚刚构建了什么{PLAN_OR_REQUIREMENTS} - 它应该做什么{BASE_SHA} - 起始提交{HEAD_SHA} - 结束提交{DESCRIPTION} - 简要摘要3. 根据反馈行动：
4. 审查通过后自动推进：
审查通过
↓ 自动进入
sw-task-verification（功能验证）
↓ 通过
标记任务完成 → 进入下一任务审查不通过 → 修复 → 重新审查（循环最多 3 次）
当收到代码审查反馈时（无论是来自子 Agent 审查者还是外部审查者），自动进入处理流程。
1. 阅读：完整阅读反馈，不做反应
2. 理解：用自己的话重述要求（或询问）
3. 验证：根据代码库现实检查
4. 评估：对此代码库技术上合理吗？
5. 回应：技术确认或有理有据的反驳
6. 实现：一次一项，每项都测试绝不：
改为：
如果任何项目不清晰：
停止 - 还不要实现任何东西
询问不清晰项目的澄清示例：
用户："修复 1-6"
你理解 1,2,3,6。不清楚 4,5。
❌ 错误：现在实现 1,2,3,6，稍后询问 4,5
✅ 正确："我理解项目 1,2,3,6。需要澄清 4 和 5 后再继续。"来自用户：
来自外部审查者：
实现之前：
1. 检查：对此代码库技术上正确吗？
2. 检查：会破坏现有功能吗？
3. 检查：当前实现的理由？
4. 检查：在所有平台/版本上有效吗？
5. 检查：审查者理解完整上下文吗？
如果建议似乎是错的：
用技术推理反驳
如果不能轻松验证：
说出来："我无法在没有 [X] 的情况下验证这个。我应该 [调查/询问/继续] 吗？"
如果与用户的先前决策冲突：
先与用户讨论规则： "外部反馈——保持怀疑，但仔细检查"
如果审查者建议"正确实现"：
在代码库中搜索实际使用
如果未使用："此端点未被调用。删除它 (YAGNI)？"
如果使用：那么正确实现规则： "你和审查者都向我汇报。如果我们不需要这个功能，就不要添加。"
对于多项目反馈：
1. 先澄清任何不清晰的内容
2. 然后按此顺序实现：
- 阻塞性问题（破坏、安全）
- 简单修复（拼写、导入）
- 复杂修复（重构、逻辑）
3. 单独测试每个修复
4. 验证无回归反驳当：
如何反驳：
如果不舒服大声反驳： "Strange things are afoot at the Circle K"
当反馈正确时：
✅ "已修复。[更改的简要描述]"
✅ "好发现——[具体问题]。在 [位置] 修复。"
✅ [直接修复并在代码中展示]
❌ "你说得完全正确！"
❌ "好观点！"
❌ "感谢指出！"
❌ "感谢[任何东西]"
❌ 任何感谢表达为什么不要感谢： 行动胜于言语。直接修复。代码本身表明你听到了反馈。
如果你发现自己要写"感谢"： 删除它。改为陈述修复。
如果你反驳了但错了：
✅ "你说得对——我检查了 [X]，它确实 [Y]。正在实现。"
✅ "验证了这个，你是对的。我最初的理解错了，因为 [原因]。正在修复。"
❌ 长篇道歉
❌ 为为什么反驳辩护
❌ 过度解释调用链：
sw-subagent-development 完成任务
↓ 自动
sw-code-review（本 Skill）
↓ 审查通过
sw-task-verification（功能验证）
↓ 验证通过
标记任务完成 → 进入下一任务子 Agent 驱动开发：
sw-task-verification执行计划：
临时开发：
| 维度 | sw-code-review（本 Skill） | sw-task-verification | |------|---------------------------|---------------------| | 关注点 | 代码质量（静态） | 功能正确性（动态） | | 核心问题 | "代码写得好吗？" | "功能正常工作吗？" | | 验证方式 | 代码审查、架构评估 | 运行测试、手动验证、集成测试 | | 触发时机 | 代码完成后 | 代码审查通过后 | | 不通过时 | 修复代码，重新审查 | 修复问题，重新验证 |
本 Skill 不处理： 功能测试、边界验证、回归验证 —— 这些由 sw-task-verification 负责。
| 想法 | 现实 | |------|------| | "这个很简单，不需要审查" | 简单代码也有盲点。10 分钟审查可能节省数小时调试 | | "审查者错了，忽略" | 用技术推理反驳，不是忽略。有效反馈可能来自误解 | | "先继续，稍后修复" | 问题会复合。进入下一任务前修复 | | "自审就够了" | 自审有盲点。独立审查发现不同问题 | | " deadline 紧，没空审查" | 未审查的代码会让 deadline 更紧 | | "你说得完全正确！" | 表演性同意违反 AGENTS.md。重述要求或直接行动 | | "好观点！" / "excellent feedback!" | 表演性回应浪费时间。行动 > 言语 | | "我现在就实现它" | 验证之前不实现。检查是否破坏现有功能 | | "审查者一定是对的" | 外部反馈是建议，不是命令。先验证 | | "批量修复更快" | 一次一项，每项都测试。批量 = 引入回归 |
| 借口 | 现实 | |------|------| | "审查浪费时间" | 10 分钟审查可能节省数小时调试 | | "我已经自审过了" | 自审有盲点，独立审查发现不同问题 | | "审查者不懂这个领域" | 外部视角常发现领域专家遗漏的问题 | | " deadline 紧，没空审查" | 未审查的代码 deadline 后会成为技术债务 | | "合并前再审查也行" | 问题在代码库中停留越久，修复成本越高 | | "审查者是对的，直接实现" | 外部反馈需要先验证。可能破坏现有功能 | | "批量修复更快" | 一次一项，每项测试。批量修复容易引入回归 | | "感谢反馈是礼貌" | 行动胜于言语。代码本身表明你听到了反馈 | | "反驳不舒服，就同意吧" | 技术正确性 > 社交舒适。有理有据的反驳是专业行为 | | "项目都清楚，不需要澄清" | 部分理解 = 错误实现。不清楚就询问 |
参见模板：./code-reviewer.md
Other measured skills in the registry, with their headline benchmark lift.