📚 代码审查 全难度 📦 Obra

requesting-code-review

对照计划审查,按严重程度报告问题,关键问题阻止继续。

📄 相关文章

📊 评分明细

📦 打包完整度
2.1 2.1 / 2.5
🎯 实用性
2.1 2.1 / 2.5
📖 文档清晰度
1.7 1.7 / 2
👥 社区影响力
1.2 1.2 / 1.5
🔗 集成度
1.2 1.2 / 1.5

🎯 适用场景

免费代码审查办公

requesting-code-review 快速入门

让 AI 提交代码后主动喊“我需要 review”——这个 Skill 用 3 步让 Agent 学会自检 + 主动请审。

这是什么?解决什么问题?

requesting-code-review 是 obra/superpowers 项目下的代码审查流程 Skill,关注的是 “谁来发起 review” 这个常被忽略的环节。
通常团队的 code review 是由人发起的——开发者 push 代码,开 PR,@ 同事。但在 AI 协作开发场景下,Agent 写完一段代码后往往不会主动停下来说“请帮我 review 一下”,而是继续往下做,导致质量问题被掩盖。
requesting-code-review Skill 反过来要求 Agent 主动触发 review,其核心理念来自 obra/superpowers 的 Plan-Compliance 思想:

  1. 任务完成 ≠ 工作完成,还要对照原始计划做“计划符合性检查”;
  2. 严重性分级:blocker / critical / major / minor / nit,blocker 必须先解决;
  3. 关键问题可阻断:遇到 blocker / critical,Agent 必须停下,等用户确认;
  4. 报告结构化:每条问题带文件:行号、原因、建议、改动示例。
    适合使用 Claude Code / Cursor / Aider 等 Agent 工具开发的工程师、Tech Lead,以及想给团队立“AI 协作代码审查规范”的人。

准备工作

  1. AI 编程 Agent:Claude Code 最完整,Cursor 次之。
  2. Git 仓库:Skill 会用 git diff 评估变更。
  3. Node.js ≥ 18:可选,Agent 自己会跑命令。
  4. 项目原始 plan / spec:Skill 强调要先有 plan 才能 review,没有 plan 的话,先写一份。

3 步快速上手

第 1 步:克隆 superpowers 仓库

git clone https://github.com/obra/superpowers.git<br>
cd superpowers<br>
ls skills/requesting-code-review<br>
```<br>
### 第 2 步:让 Agent 加载 Skill<br>
`CLAUDE.md`:<br>
```markdown<br>
# CLAUDE.md<br>
After completing any non-trivial code change, invoke the<br>
requesting-code-review skill from obra/superpowers before claiming<br>
the task is done. Report findings in the prescribed severity table.<br>
```<br>
### 第 3 步:跑一次完整 review 流程<br>
假设你刚让 Agent 实现了一个新功能:
> Agent,你刚才完成了“订单导出 CSV”功能,请按 requesting-code-review Skill 跑一次自检 + 请求 review。

Agent 会:

1. 调 `git status` / `git diff` 看到本次变更涉及哪些文件;

2. 调出原始 plan / spec(本项目是 `docs/order-export.md`);

3. 逐条对照 plan 检查实现是否完整;

4. 按严重性输出报告:

Review Report — order export CSV

Blocker

(none)

Critical

  • src/services/OrderExportService.java:88

未实现 plan 中要求的“按时间区间过滤”,目前导出全表。

Fix: 在 SQL 中加 created_at BETWEEN ? AND ?,并接 controller 参数。

Major

  • src/services/OrderExportService.java:120

导出 100 万行时未分页,容易 OOM。Plan 要求 batch size 1000。

Fix: 用 Stream + JDBC fetchSize 分批。

Minor

  • src/main/resources/application.yml:15

CSV 编码未配置,中文会乱码。建议加 spring.servlet.encoding.charset=UTF-8


## 常见踩坑

1. **没有 plan / spec**:Skill 强调没有 plan 就不存在 plan-compliance,review 会流于形式。建议每个 feature 先有 `docs/<feature>.md`。

2. **报告没有 file:行号**:Skill 强制要求 `path:line` 格式,否则 review 完没法落实。

3. **把 nit 标成 critical**:会让 reviewer 疲劳。Skill 提供 `severity 决策表`,例如“拼写错误 = nit,空指针风险 = critical”。

4. **blocker 没真正阻断流程**:有些 Agent 写完 review 报告就接着跑下一个任务,违反 Skill 规则。CLAUDE.md 里要写明“blocker 不解除则停止”。

5. **跳过 positive feedback**:Skill 提示也要报告“做得好的部分”,但很多人忘了加。

6. **没区分人类 review 与 AI 自检**:AI 自检可能漏掉 UX / 业务语义,Skill 建议最后必须有一次人类 review。

## 初级用法

**1. 单文件改动**

> 我刚把 `user.service.ts` 改了一下,请用 requesting-code-review Skill 走一遍 review。

**2. 一次完整 PR**

> 我要提一个 PR 包含 `auth/login.ts`、`auth/jwt.ts`、`tests/auth.test.ts` 三个文件,请帮我做一次完整 review。

**3. 对照原 issue**

> 这是 #142 修复,需求在 `docs/issues/142.md`,请用 Skill 做 plan-compliance 检查。

## 高级玩法

**1. CI 集成自动 review**

```yaml

- name: AI Code Review

run: |

claude --skill requesting-code-review --diff origin/main..HEAD > review.md

gh pr comment --body-file review.md

2. 团队共享 review 模板

把 Skill 的 severity 决策表抽到 .review-config.yml,团队所有项目共享。

3. 跟 git-hook 配合


# .git/hooks/post-commit

claude --skill requesting-code-review --last-commit

每次 commit 自动跑一次自检。

4. 与 receiving-code-review 联动

别人给你的 review 反馈,用 obra 的另一个 receiving-code-review Skill 处理回复节奏,形成完整闭环。

小技巧

  • 每次 review 前先看 plan:没 plan 不 review。

  • severity 用全大写:BLOCKER / CRITICAL / MAJOR / MINOR / NIT,易于 grep。

  • 报告模板化:用 Markdown 表格,贴 PR 评论更易读。

  • review 完别忘了 +1 commit:Agent 修复 blocker 后要明确标“fixed in ”,方便追溯。

  • 人类最后过一遍:AI review 抓不到业务语义,人是兜底。

参考链接

requesting-code-review Skill 多维度简评

类别:工程方法 来源:obra/superpowers 定位:主动请求代码审查的标准化流程 —— 让 review 高效、减少来回沟通。


一、项目背景

requesting-code-review 是 obra/superpowers 框架中的代码审查方法论 Skill,与 receiving-code-review 配对使用。该 Skill 面向代码提交方,定义了在提交 PR(Pull Request)时如何准备清晰的审查上下文,使 reviewer 能够高效理解变更意图。

核心信条:Early & often——尽早审查、频繁审查。小反馈循环避免大规模返工。


二、标准化 Review 请求模板

该 Skill 要求每次请求 review 时包含以下要素:

要素说明
上下文摘要本次变更的背景、解决什么问题、为什么这样解决
自审 Checklist提交前自行检查的清单(测试通过、无 debug 代码等)
具体 review 点明确标注希望 reviewer 重点关注的部分
变更可视化截图、GIF 或录屏展示 UI/UX 变更
时间预估评估 review 所需时间,帮助 reviewer 安排时间

三、自审 Checklist(提交前必须通过)

在请求 review 之前,提交方应自行确认:

  1. 所有测试通过(单元测试、集成测试)
  2. 无遗留的 debug 代码、console.log、注释掉的代码
  3. 代码风格符合项目规范
  4. 相关文档已更新
  5. UI 变更已在多分辨率/浏览器测试
  6. 边界情况和错误状态已处理
  7. PR 的 diff 范围合理(避免超大 PR)

四、Red Flags(禁止做法)

  • 跳过 review 因为”改动很简单”
  • 忽略 Critical 级别 的反馈
  • 在未修复 Important 级别反馈的情况下继续推进
  • 对有效的技术反馈进行无理由争论

五、在 Superpowers 框架中的位置

该 Skill 在 Superpowers 14 步方法论中处于”审查”阶段,与 TDD(测试驱动开发)和 verification-before-completion(完成前验证)紧密配合。

审查阶段流程:
TDD 通过 → requesting-code-review(请求审查)→ 
reviewer 反馈 → receiving-code-review(接收反馈)→ 
修改 → 再次 requesting → 通过 → finishing-a-development-branch

六、安装

npx skills add obra/superpowers --skill requesting-code-review

七、注意事项

  • 高效的代码审查需要团队文化支撑——避免 blame、鼓励学习。
  • PR 的 diff 大小直接影响 review 质量,小 PR(< 400 行变更)效果最好。
  • 本文基于官方文档和公开资料整理,未经过 MagicNetWorld 实测。

参考资料

📊 评分与标签

评分说明

总分 8.3/10 · P_优选

📊 可观测社区指标(数据核验日期:2026-07-23)

  • 官方仓库与维护入口:obra/superpowers。GitHub API 核验时触发限流,未记录无法再次确认的 Stars/Forks 精确快照,避免用估算值替代事实。

📦 可安装性 2.1/2.5

  • 官方来源提供可复制的 Skill、MCP 或 Markdown 目录;安装前仍需按 README 配置宿主客户端、运行时和最小权限凭据。
  • 与 Anthropic Skills、OpenCode Skills 对比,本项遵循开放目录思路,但插件命令、脚本依赖和更新方式并不完全统一。

🎯 实用性 2.2/2.5

  • 提交审查、严重度分级和关键问题阻断;这里只确认官方材料明确描述的范围,未把未经实测的准确率、性能或生产收益计入评分。
  • 与 GitHub CLI、Zapier 等专用工具对比,Skill 更适合把操作步骤交给 Agent 复用,不能替代完整运行时、监控和人工验收。

📖 文档质量 1.7/2.0

  • README、技能目录或官方参考页可核对安装、能力和约束;未发现统一的端到端性能基准,因此采用保守文档分。
  • 与 Vercel Agent Skills、Obra Superpowers 对比,目标任务说明直接,但版本迁移、失败恢复和跨平台案例仍依赖上游维护。

👥 社区活跃 1.1/1.5

  • 仓库公开提交历史、Issue 与 Pull Request 入口可追踪维护;因 API 限流未写入易变精确计数,社区分不依据未经复核的热度数字。
  • 与 anthropics/skills、obra/superpowers 对比,具备公开协作入口,但不能据此推导响应时效、长期承诺或企业支持等级。

🔗 兼容性 1.2/1.5

  • 可在能够读取 Skills/MCP 指令并具备相应工具权限的 Agent 环境使用;API、Token、浏览器和本地工具链会形成额外约束。
  • 与 Claude Code、Codex、Cursor 的原生扩展对比,开放文件格式便于迁移,但触发、脚本执行和资源加载行为存在客户端差异。

评分依据可追溯至公开来源,每项分数均有明确理由和数据支撑。

🏷️ 标签说明

  • 免费: 公开来源可访问;外部服务费用不计入 Skill 本身。来源:官方来源
  • 代码审查: 核心能力与“提交审查、严重度分级和关键问题阻断”直接对应。来源:官方来源
  • 办公: 官方材料显示其面向该使用方式。来源:官方来源

局限说明:本次为官方仓库与文档核验,未执行跨客户端、跨操作系统端到端基准测试;外部 API 配额、授权和价格可能变化,应以上游最新说明为准。

📋 来源与核验记录