关于 requesting-code-review
面向使用支持工作者能力的客户端或进行新一轮顺序审查的开发者的代码审查 Skill。它以固定代码快照为依据,规定独立审查、反馈处理和修复后的复核流程。
主要功能
- 01派发审查工作者
- 02审查固定提交快照
- 03合并前要求跨提供商审查
- 04按优先级处理反馈
- 05在更新快照上验证修复
适用场景
- 01审查子 Agent 开发中的每项任务
- 02合并前检查重大功能
- 03遇到阻塞时获取新视角
- 04复核复杂缺陷修复
安装
复制下面的命令,在终端中运行。
npx skills add https:/ / github.com/ jamditis/ claude-skills-journalism --skill requesting-code-review安装后在 Claude Code 中输入/requesting-code-review确认已加载。
包含的文件
除 SKILL.md 外,安装时一起下载的参考资料和脚本。
code-reviewer.mdagents/openai.yamlreferences/cross-provider-review.md详细介绍
请求代码审查
如果客户端支持,请派遣代码审查子 Agent 或并行工作进程,在问题扩散前发现问题。在 Claude Code 中,派遣 pr-review-toolkit:code-reviewer。向审查者提供准确的上下文,而不是完整的会话历史。这样可以让审查者专注于产出,而不是你的思考过程,并为你后续工作保留自己的上下文。如果客户端不支持工作进程,请在新的审查环节中按顺序执行同样的审查。
核心原则: 尽早审查,经常审查。
独立性规则: 合并前,独立审查应由代码编写者以外的模型提供方执行。根据风险调整审查投入:简单的改动投入较少,涉及行为、安全、数据或大范围改动则投入较多。同一提供方的审查仍可在任务期间发现问题,但不算独立审查。
何时请求审查
必须:
- 子 Agent 驱动开发中的每项任务完成后
- 重大功能完成后
- 合并到 main 之前
可选但有价值:
- 遇到阻碍时(获得新视角)
- 重构前(检查基线)
- 修复复杂 Bug 后
如何请求
1. 获取 git SHA:
BASE_SHA=$(git rev-parse HEAD~1) # or origin/main
HEAD_SHA=$(git rev-parse HEAD)
2. 派遣代码审查子 Agent:
使用客户端的工作进程能力,并填写 code-reviewer.md 中的模板。在 Claude Code 中,使用 Task 工具调用 pr-review-toolkit:code-reviewer。
占位符:
{WHAT_WAS_IMPLEMENTED}- 刚刚实现的内容{PLAN_OR_REQUIREMENTS}- 应实现的行为{BASE_SHA}- 起始提交{HEAD_SHA}- 结束提交{DESCRIPTION}- 简短摘要
3. 固定快照:
记录基准、头部、变更路径和 diff 摘要。请审查者复述这些信息。若审查覆盖的是不同快照,则丢弃其结果。如果审查后修改了代码,旧结果就不再覆盖当前头部。
4. 处理反馈:
- 立即修复严重问题
- 继续之前修复重要问题
- 将次要问题记录下来,以后处理
- 如果审查者有误,请给出理由并提出异议
- 修复后,让同一位审查者针对新快照执行一次重点验证修复审查
不要因为第一位审查者发现了问题或返回了格式错误的输出就更换审查者。仅当审查者的提供方不可用时才更换。审查轮次没有上限;当审查者确认当前精确头部没有可处理的缺陷时即可停止。
示例
[Just completed Task 2: Add verification function]
You: Let me request code review before proceeding.
BASE_SHA=$(git log --oneline | grep "Task 1" | head -1 | awk '{print $1}')
HEAD_SHA=$(git rev-parse HEAD)
[Dispatch a code-review worker from a different provider]
WHAT_WAS_IMPLEMENTED: Verification and repair functions for conversation index
PLAN_OR_REQUIREMENTS: Task 2 from docs/superpowers/plans/deployment-plan.md
BASE_SHA: a7981ec
HEAD_SHA: 3df7661
DESCRIPTION: Added verifyIndex() and repairIndex() with 4 issue types
[Subagent returns]:
Strengths: Clean architecture, real tests
Issues:
Important: Missing progress indicators
Minor: Magic number (100) for reporting interval
Assessment: Ready to proceed
You: [Fix progress indicators]
[Continue to Task 3]
与工作流集成
子 Agent 驱动开发:
- 每项任务完成后审查
- 在问题累积前发现它们
- 修复后再进入下一项任务
执行计划:
- 每批任务(3 项)完成后审查
- 获取反馈、应用修改,然后继续
临时开发:
- 合并前审查
- 遇到阻碍时审查
警示信号
绝不:
- 因为“很简单”就跳过审查
- 忽略严重问题
- 在重要问题未修复时继续
- 与合理的技术反馈争辩
如果审查者有误:
- 以技术理由提出异议
- 提供能证明其有效的代码或测试
- 请求澄清
请参阅模板:requesting-code-review/code-reviewer.md
参考文件
当独立审查者必须验证已完成的改动时,请阅读 跨提供方代码审查。