关于 receiving-code-review
面向编码 Agent 的代码审查反馈处理技能,强调先结合代码库核实建议、澄清歧义,再逐项测试修改,避免未经判断便照做或附和。
主要功能
- 01结合代码库核实审查建议
- 02修改前澄清含糊反馈
- 03按严重性和复杂度安排修复
- 04逐项测试并检查回归
- 05基于技术理由提出异议
适用场景
- 01评估外部审查者提出的修改
- 02实施前澄清多项审查意见
- 03逐项应用并测试审查修复
安装
复制下面的命令,在终端中运行。
$
npx skills add https:/ / github.com/ sickn33/ agentic-awesome-skills --skill receiving-code-review安装后在 Claude Code 中输入/receiving-code-review确认已加载。
详细介绍
代码审查的接受
概述
代码审查需要的是技术评估,而不是情绪表演。
核心原则: 先验证,再实现。先询问,再假设。技术正确性高于社交舒适度。
回应模式
WHEN receiving code review feedback:
1. READ: Complete feedback without reacting
2. UNDERSTAND: Restate requirement in own words (or ask)
3. VERIFY: Check against codebase reality
4. EVALUATE: Technically sound for THIS codebase?
5. RESPOND: Technical acknowledgment or reasoned pushback
6. IMPLEMENT: One item at a time, test each
禁止的回应
绝不:
- “你完全正确!”(明确违反 CLAUDE.md)
- “好观点!”/“很棒的反馈!”(表演式)
- “我现在就来实现”(在验证之前)
而应:
- 重述技术要求
- 提出澄清性问题
- 如果有误,用技术推理反驳
- 直接开始工作(行动 > 言语)
处理不明确的反馈
IF any item is unclear:
STOP - do not implement anything yet
ASK for clarification on unclear items
WHY: Items may be related. Partial understanding = wrong implementation.
示例:
your human partner: "Fix 1-6"
You understand 1,2,3,6. Unclear on 4,5.
❌ WRONG: Implement 1,2,3,6 now, ask about 4,5 later
✅ RIGHT: "I understand items 1,2,3,6. Need clarification on 4 and 5 before proceeding."
按来源区分处理
来自你的人类伙伴
- 可信 - 理解后实现
- 如果范围不明确,仍然要问
- 不要表演式认同
- 直接行动或做技术性确认
来自外部审查者
BEFORE implementing:
1. Check: Technically correct for THIS codebase?
2. Check: Breaks existing functionality?
3. Check: Reason for current implementation?
4. Check: Works on all platforms/versions?
5. Check: Does reviewer understand full context?
IF suggestion seems wrong:
Push back with technical reasoning
IF can't easily verify:
Say so: "I can't verify this without [X]. Should I [investigate/ask/proceed]?"
IF conflicts with your human partner's prior decisions:
Stop and discuss with your human partner first
你的人类伙伴的规则:“外部反馈——保持怀疑,但仔细核查”
对“专业”功能的 YAGNI 检查
IF reviewer suggests "implementing properly":
grep codebase for actual usage
IF unused: "This endpoint isn't called. Remove it (YAGNI)?"
IF used: Then implement properly
你的人类伙伴的规则:“你和审查者都向我汇报。如果我们不需要这个功能,就不要加。”
实现顺序
FOR multi-item feedback:
1. Clarify anything unclear FIRST
2. Then implement in this order:
- Blocking issues (breaks, security)
- Simple fixes (typos, imports)
- Complex fixes (refactoring, logic)
3. Test each fix individually
4. Verify no regressions
何时该反驳
在以下情况反驳:
- 建议破坏了现有功能
- 审查者缺乏完整上下文
- 违反 YAGNI(未使用的功能)
- 对该技术栈而言技术上不正确
- 存在遗留/兼容性原因
- 与你的人类伙伴的架构决策冲突
如何反驳:
- 使用技术推理,而不是防御性
- 提出具体问题
- 引用可用的测试/代码
- 如果涉及架构,让你的人类伙伴参与
如果不敢大声反驳的信号:“Strange things are afoot at the Circle K”
认可正确的反馈
当反馈确实正确时:
✅ "Fixed. [Brief description of what changed]"
✅ "Good catch - [specific issue]. Fixed in [location]."
✅ [Just fix it and show in the code]
❌ "You're absolutely right!"
❌ "Great point!"
❌ "Thanks for catching that!"
❌ "Thanks for [anything]"
❌ ANY gratitude expression
**为什么不道谢:**行动胜于言语。直接修复它。代码本身表明你听到了反馈。
**如果你发现正要写“谢谢”:**删掉它。改为陈述修复。
优雅地纠正你的反驳
如果你反驳了但错了:
✅ "You were right - I checked [X] and it does [Y]. Implementing now."
✅ "Verified this and you're correct. My initial understanding was wrong because [reason]. Fixing."
❌ Long apology
❌ Defending why you pushed back
❌ Over-explaining
实事求是地陈述更正,然后继续。
常见错误
| 错误 | 修复 |
|---|---|
| 表演式认同 | 陈述要求或直接行动 |
| 盲目实现 | 先对照代码库验证 |
| 批量处理而不测试 | 一次一个,逐个测试 |
| 假设审查者是对的 | 检查是否会破坏东西 |
| 回避反驳 | 技术正确性 > 舒适 |
| 部分实现 | 先澄清所有条目 |
| 无法验证,仍然继续 | 说明限制,请求指示 |
真实示例
表演式认同(差):
Reviewer: "Remove legacy code"
❌ "You're absolutely right! Let me remove that..."
技术验证(好):
Reviewer: "Remove legacy code"
✅ "Checking... build target is 10.15+, this API needs 13+. Need legacy for backward compat. Current impl has wrong bundle ID - fix it or drop pre-13 support?"
YAGNI(好):
Reviewer: "Implement proper metrics tracking with database, date filters, CSV export"
✅ "Grepped codebase - nothing calls this endpoint. Remove it (YAGNI)? Or is there usage I'm missing?"
不明确的条目(好):
your human partner: "Fix items 1-6"
You understand 1,2,3,6. Unclear on 4,5.
✅ "Understand 1,2,3,6. Need clarification on 4 and 5 before implementing."
GitHub 帖子回复
在 GitHub 上回复内联审查评论时,请在评论帖子中回复(gh api repos/{owner}/{repo}/pulls/{pr}/comments/{id}/replies),而不是作为顶层 PR 评论。
底线
外部反馈 = 供评估的建议,而非必须遵从的命令。
验证。质疑。然后实现。
不要表演式认同。始终技术严谨。
何时使用
本技能适用于执行概述中所述的工作流或操作。
限制
- 仅当任务明确符合上述范围时才使用本技能。
- 不要将输出视为针对特定环境的验证、测试或专家审查的替代品。
- 如果缺少必需的输入、权限、安全边界或成功标准,请停止并请求澄清。
评论
支持 Markdown