开发与工程 workflowcode-reviewsubagentssuperpowers

Requesting Code Review(发起代码评审)

派一个独立上下文的评审子代理来审查改动,而不是让主会话自己一边写一边给自己打分

FollowSkills 评估 · FSRS-1.0
谨慎使用
64/ 100
价值适配16 / 20

该技能针对完成任务、重大功能和合并前的代码审查,能通过隔离上下文的审查子代理及按严重性处理反馈来降低缺陷扩散风险。目标受众和触发时机清晰,但适用边界、审查失败时的替代流程以及不同项目类型的适配说明不足。

可靠性11 / 20

流程包含获取 BASE_SHA/HEAD_SHA、填充审查模板、按 Critical/Important/Minor 处理反馈,并要求只读审查,具有一定可重复性。证据未说明子代理不可用、Git 历史不足、提交范围错误、模板文件缺失或审查结果不完整时如何处理,也没有该技能自身的自动化行为测试。

安全性18 / 25

审查模板明确要求只读,不修改工作树、索引、HEAD 或分支状态,并建议使用独立 worktree 检查其他修订,降低了直接改动风险。技能仍会把代码变更、需求和 Git 差异发送给子代理,未说明敏感信息脱敏、用户同意、访问权限边界、外部服务数据流或反馈修复前后的回滚策略。

证据8 / 15

技能要求审查 Git diff、计划对齐、错误处理、安全性、测试和生产准备度,并要求文件行号、影响和修复建议,具备基本可追溯性。静态材料没有显示该技能的执行测试、独立评估或实际审查样例;模板中的测试与合并结论是期望输出,不是已验证事实,且未明确区分观察结果与推断。

易用性7 / 10

触发条件、三步操作、占位符和预期审查输出都较明确,用户可以理解何时调用以及如何处理反馈。仍缺少子代理调度的具体接口/配置、输入缺失时的处理、成本与耗时提示、跨代理兼容性要求、故障排查以及在审查无法完成时的退出标准。

维护性4 / 10

技能有稳定的名称和描述,且相邻模板定义了较完整的审查格式。选定技能本身没有版本、变更记录、维护者、响应承诺或更新路径;仓库提供 MIT 许可和版本信息,但发布者 provenance 未经企业注册表验证,不能据此增加治理或维护分数。

证据充分度: 评估于 2026年7月15日 审查版本 d884ae04edeb
使用前请注意
  • 发送代码、需求和 Git diff 前,应确认其中不含凭据、个人数据或机密,并明确子代理及其运行环境的访问范围。
  • 不要把模板要求的“测试通过”或“可合并”当作已验证事实;当前评估未执行该技能或任何独立测试。
  • 应补充审查子代理不可用、Git SHA 无效、模板缺失或反馈冲突时的停止、重试和人工接管流程。
查看完整评分方法 →

它能做什么 & 适用场景

在完成一项任务、一个大功能,或合并主干前,派发一个只拿到必要上下文(描述、需求、起止 commit SHA)的评审子代理,而不是自己继续用同一个上下文自我评审。这样评审关注的是产出物本身而不是主会话的思考过程,也不占用主会话的上下文。文档很短,核心是「什么时候必须评审」「怎么派发」「怎么处理反馈」三段。

先取出起止 commit 的 SHA;用 code-reviewer.md 模板派发一个 general-purpose 子代理,填入改动描述、需求/计划、起止 SHA 四个占位符;根据评审子代理返回的反馈按严重程度处理——Critical 立刻修,Important 在继续前修,Minor 记录留待后续;如果认为评审子代理判断错了,允许带着技术理由反驳。列出了「必须评审」的场景(subagent-driven-development 每个任务之后、完成大功能后、合并主干前)和「建议评审」的场景(卡壳时、重构前建立基线、修完复杂 bug 后)。

  1. subagent-driven-development 流程里每完成一个任务,派发一次子代理评审再继续下一个任务
  2. 合并到主干前,用独立上下文的评审子代理做一次把关,而不是自己审自己写的代码
  3. 卡壳时主动请一次评审,借助「新鲜视角」换个人(子代理)看问题

优缺点一览

优点
  • 评审子代理拿到的是精心构造的上下文而不是主会话完整历史,评审更聚焦在改动本身
  • 给出了具体的严重度处理顺序(Critical 立即修/Important 继续前修/Minor 记录后续),避免「有问题但先放着」变成无限拖延
  • 明确允许对评审子代理的判断提出技术性反驳,不是单向的「评审说了算」
局限
  • 只在会自动读取和遵循 SKILL.md 指令的 harness 里可靠工作(Claude Code、Codex CLI 等);纯聊天式界面里等于一份说明文档,需要人工照做。
  • 依赖 code-reviewer.md 这个模板文件(skill 目录内),如果只看主 SKILL.md 而没找到模板,流程会不完整
  • 评审质量取决于子代理本身的能力和给到的上下文是否完整,模板填得潦草,评审也会流于表面

如何安装

作为 obra/superpowers 插件的一部分安装,不能单独安装某一个 skill:

  1. Claude Code:官方市场 /plugin install superpowers@claude-plugins-official;或先注册 Superpowers 自建市场 /plugin marketplace add obra/superpowers-marketplace,再 /plugin install superpowers@superpowers-marketplace
  2. 也支持 Antigravity、Codex App/CLI、Cursor、Factory Droid、GitHub Copilot CLI、Kimi Code、OpenCode、Pi 等 harness,具体命令见仓库 README

装好后这个 skill 会和其余 13 个 Superpowers skill 一起启用,由 using-superpowers 统一引导、按场景自动触发,无需单独调用。

如何使用

在完成任务节点时被自动或主动调用,核心动作是取 git SHA 区间、填 code-reviewer.md 模板、派发子代理,收到反馈后按严重度分级处理。

对比同类

跟没有独立评审、靠模型自己在同一上下文里做完再回头检查一遍相比,这个 skill 通过「独立子代理 + 精心构造的评审上下文」提供了更接近真实团队代码评审的隔离性;跟 subagent-driven-development 里内置的两阶段评审相比,这个 skill 更通用、可以在任意开发流程的节点上单独调用。

常见问题

什么时候是「必须」评审,什么时候只是「建议」?
必须:subagent-driven-development 每个任务后、完成大功能后、合并主干前。建议但有价值:卡壳时、重构前、修完复杂 bug 后。

同仓库的其他 Skills

均来自 obra/superpowers

开发与工程

Test-Driven Development(测试驱动开发)

铁律:没有先写失败测试就不能写生产代码,写了也要删掉重来,不允许「补测试」

开发与工程

Brainstorming(需求澄清与设计)

写代码前先把需求逼问清楚,禁止在没有确认设计前直接动手实现

开发与工程

Verification Before Completion(完成前必须验证)

没有当次运行过的验证证据,就不能说「完成了」「测试通过了」——包括「应该」「看起来」这类措辞

开发与工程

Finishing a Development Branch(收尾开发分支)

开发完成后先验证测试通过,再用固定的 4 选项菜单让人决定合并/PR/保留/丢弃,并按规则清理 worktree

开发与工程

Receiving Code Review(接收代码评审反馈)

禁止「你说得对!」式的表演性附和,要求先核实反馈再决定实施还是据理反驳

开发与工程

Systematic Debugging(系统化调试)

任何 bug 都必须先完成根因排查再提修复方案,明确禁止「先随手改一下试试」

开发与工程

Writing Plans(撰写实现计划)

把需求拆成假设执行者对代码库一无所知也能照做的、每步 2-5 分钟的具体任务,杜绝「TBD」「补充细节」类占位符

开发与工程

Subagent-Driven Development(子代理驱动开发)

同一会话内为每个任务派发全新子代理实现,配两阶段审查,用进度台账防止压缩后重复劳动

开发与工程

Executing Plans(分会话执行实现计划)

在没有子代理能力的场景下,按人工检查点批量执行一份已写好的实现计划

开发与工程

Using Git Worktrees(隔离工作区管理)

开始新功能开发前,优先用平台原生隔离工具,没有的话再退回手动 git worktree

开发与工程

Dispatching Parallel Agents(并行子代理调度)

面对多个互不依赖的问题时,一次性并行派发多个子代理分别处理,而不是串行排队

开发与工程

Writing Skills(撰写与测试 Skill 本身)

把 TDD 的红绿重构套用到「写 Skill 文档」这件事上:先用无 skill 基线测试暴露真实失败模式,再针对性写文档,而不是凭直觉写

开发与工程

Using Superpowers(Superpowers 入口引导)

整套 Superpowers 方法论的启动引导 skill,规定「只要有 1% 可能相关就必须调用对应 skill」

相关 Skills