requesting-code-review
- 信任分
- 88/100
- 兼容 Agent
- 1
- 领域
- 工程开发
- 兼容 Agent
- Claude Code
- 信任分
- 88 / 100 · 社区维护
- 作者 / 版本 / 许可
- @obra · 未声明 license
- 安装命令数
- 1 条
需要注意： 未限定 allowed-tools，默认拥有全部工具权限。
想读作者英文原文？ ↓ 滚到正文区切换 · 在 GitHub 查看 ↗
requesting-code-review 把「发起 code review」也变成一个独立技能——核心创新是：reviewer 不读你的对话历史，只读你精心构造的上下文。这避免 reviewer 被你思考过程里的杂念带偏，同时把你自己的 context 留给后续工作。
设计思路
作者主张「Review early, review often」——通过 subagent 在每个关键节点抓 review。reviewer 是子 agent，被分配一份「该评估什么、对照什么需求、看哪两个 SHA 之间的 diff」的任务卡，从干净状态开始评估。
工作流
① 取 SHA：BASE_SHA=$(git rev-parse HEAD~1) / HEAD_SHA=$(git rev-parse HEAD)；② 用 Task 工具调起 general-purpose 类型的 reviewer，按 code-reviewer.md 模板填四个占位符——{DESCRIPTION}（你做了什么的简述）、{PLAN_OR_REQUIREMENTS}（应该做到什么）、{BASE_SHA} / {HEAD_SHA}；③ 接收 reviewer 给的 Strengths + Issues（按 Critical/Important/Minor 分级）+ Assessment；④ Critical 立即修、Important 继续之前修、Minor 记账延后、reviewer 错就带理由反驳。
何时该用
强制：subagent-driven development 每条任务结束后；完成大功能后；合并前。可选高价值：卡住时让外部视角看一眼；重构前留一份 baseline；修完复杂 bug 后。
整合到工作流
- subagent-driven-development：每条任务后 review 一次，issue 早抓早便宜，问题修完再做下一条；
- executing-plans：每条任务或自然检查点 review；
- ad-hoc 开发：合并前 review、卡住时 review。
红线
不能因「这很简单」跳过 review；不能忽略 Critical；不能带着未修的 Important 继续；不能跟正确的技术反馈吵。如果 reviewer 错了——拿技术理由反驳，给出能跑的代码 / 测试做证据，必要时让 your human partner 仲裁。
配套
receiving-code-review（reviewer 反馈过来怎么处置）、subagent-driven-development（最常配套使用的开发节奏）、verification-before-completion（review 前你自己先验过一遍）。
Requesting Code Review
Dispatch a code reviewer subagent to catch issues before they cascade. The reviewer gets precisely crafted context for evaluation — never your session's history. This keeps the reviewer focused on the work product, not your thought process, and preserves your own context for continued work.
Core principle: Review early, review often.
When to Request Review
Mandatory:
- After each task in subagent-driven development
- After completing major feature
- Before merge to main
Optional but valuable:
- When stuck (fresh perspective)
- Before refactoring (baseline check)
- After fixing complex bug
How to Request
1. Get git SHAs:
BASE_SHA=$(git rev-parse HEAD~1) # or origin/main
HEAD_SHA=$(git rev-parse HEAD)2. Dispatch code reviewer subagent:
Use Task tool with general-purpose type, fill template at code-reviewer.md
Placeholders:
{DESCRIPTION}- Brief summary of what you built{PLAN_OR_REQUIREMENTS}- What it should do{BASE_SHA}- Starting commit{HEAD_SHA}- Ending commit
3. Act on feedback:
- Fix Critical issues immediately
- Fix Important issues before proceeding
- Note Minor issues for later
- Push back if reviewer is wrong (with reasoning)
Example
[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 code reviewer subagent]
DESCRIPTION: Added verifyIndex() and repairIndex() with 4 issue types
PLAN_OR_REQUIREMENTS: Task 2 from docs/superpowers/plans/deployment-plan.md
BASE_SHA: a7981ec
HEAD_SHA: 3df7661
[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]Integration with Workflows
Subagent-Driven Development:
- Review after EACH task
- Catch issues before they compound
- Fix before moving to next task
Executing Plans:
- Review after each task or at natural checkpoints
- Get feedback, apply, continue
Ad-Hoc Development:
- Review before merge
- Review when stuck
Red Flags
Never:
- Skip review because "it's simple"
- Ignore Critical issues
- Proceed with unfixed Important issues
- Argue with valid technical feedback
If reviewer wrong:
- Push back with technical reasoning
- Show code/tests that prove it works
- Request clarification
See template at: requesting-code-review/code-reviewer.md