代码审查接收指南：技术验证与高效响应流程 | 代码质量提升

receiving-code-review by sickn33/antigravity-awesome-skills

247 周安装量

27,400 GitHub Stars

GitHub

安装命令

npx skills add https://github.com/sickn33/antigravity-awesome-skills --skill receiving-code-review

方法论开发代码规范

🇨🇳中文介绍

代码审查接收指南

概述

代码审查需要技术评估，而非情感表现。

核心原则： 验证后再实施。询问后再假设。技术正确性优先于社交舒适度。

响应模式

当收到代码审查反馈时：

1. 阅读：完整阅读反馈内容，不做反应
2. 理解：用自己的话重述需求（或询问）
3. 验证：对照代码库实际情况检查
4. 评估：对此代码库在技术上是否合理？
5. 响应：技术性确认或有理有据的反对
6. 实施：逐项处理，每项都进行测试

禁止的回应

绝对不要：

"你说得完全正确！"（明确违反 CLAUDE.md）
"好观点！" / "优秀的反馈！"（表演性回应）
"我现在就实施这个"（在验证之前）

应该：

重述技术需求
提出澄清性问题
如果错误，用技术推理进行反驳
直接开始工作（行动胜于言语）

处理不明确的反馈

如果任何项目不明确：
  停止 - 暂时不要实施任何内容
  询问不明确项目的澄清

原因：项目可能相互关联。部分理解 = 错误实施。

示例：

你的合作伙伴："修复第1-6项"
你理解第1,2,3,6项。对第4,5项不明确。

❌ 错误：现在实施第1,2,3,6项，稍后询问第4,5项
✅ 正确："我理解第1,2,3,6项。在继续之前需要澄清第4和第5项。"

来源特定处理

广告位招租

在这里展示您的产品或服务

触达数万 AI 开发者，精准高效

联系我们

来自你的合作伙伴

可信 - 理解后实施
仍要询问 如果范围不明确
不要表演性同意
直接行动 或进行技术性确认

来自外部审查者

在实施之前：
  1. 检查：对此代码库在技术上是否正确？
  2. 检查：是否会破坏现有功能？
  3. 检查：当前实现的原因是什么？
  4. 检查：是否在所有平台/版本上都能工作？
  5. 检查：审查者是否理解完整上下文？

如果建议似乎错误：
  用技术推理进行反驳

如果无法轻易验证：
  如实说明："没有[X]我无法验证这个。我应该[调查/询问/继续]吗？"

如果与你合作伙伴之前的决定冲突：
  先停止并与你的合作伙伴讨论

你合作伙伴的规则： "外部反馈 - 保持怀疑，但要仔细检查"

"专业"功能的YAGNI检查

如果审查者建议"正确实施"：
  在代码库中搜索实际使用情况

  如果未使用："这个端点没有被调用。移除它（YAGNI）？"
  如果已使用：那么正确实施

你合作伙伴的规则： "你和审查者都向我汇报。如果我们不需要这个功能，就不要添加。"

对于多项目反馈：
  1. 首先澄清所有不明确的内容
  2. 然后按此顺序实施：
     - 阻塞性问题（破坏性、安全性）
     - 简单修复（拼写错误、导入）
     - 复杂修复（重构、逻辑）
  3. 单独测试每个修复
  4. 验证没有回归问题

在以下情况下进行反驳：

建议会破坏现有功能
审查者缺乏完整上下文
违反YAGNI（未使用的功能）
对此技术栈在技术上不正确
存在遗留/兼容性原因
与你合作伙伴的架构决策冲突

使用技术推理，而非防御性态度
提出具体问题
引用有效的测试/代码
如果涉及架构问题，请让你的合作伙伴参与

如果不方便公开反驳的信号： "Circle K发生了奇怪的事情"

确认正确的反馈

当反馈正确时：

✅ "已修复。[简要描述更改内容]"
✅ "发现得好 - [具体问题]。已在[位置]修复。"
✅ [直接修复并在代码中展示]

❌ "你说得完全正确！"
❌ "好观点！"
❌ "感谢发现这个问题！"
❌ "感谢[任何内容]"
❌ 任何感激表达

为什么不感谢： 行动胜于言语。直接修复。代码本身表明你听到了反馈。

如果你发现自己要写"感谢"： 删除它。改为说明修复内容。

优雅地纠正你的反驳

如果你反驳了但你是错误的：

✅ "你是对的 - 我检查了[X]，它确实[Y]。现在实施。"
✅ "已验证这个，你是正确的。我最初的理解错误是因为[原因]。正在修复。"

❌ 长篇道歉
❌ 为你为什么反驳进行辩护
❌ 过度解释

事实性地陈述纠正内容并继续前进。

错误	修复方法
表演性同意	陈述需求或直接行动
盲目实施	先对照代码库验证
批量处理不测试	逐项处理，每项都测试
假设审查者正确	检查是否会破坏功能
避免反驳	技术正确性 > 舒适度
部分实施	首先澄清所有项目
无法验证但仍继续	说明限制，请求指导

表演性同意（错误）：

审查者："移除遗留代码"
❌ "你说得完全正确！让我移除那个..."

技术验证（正确）：

审查者："移除遗留代码"
✅ "正在检查...构建目标是10.15+，这个API需要13+。需要遗留代码用于向后兼容。当前实现有错误的bundle ID - 修复它还是放弃13之前的支持？"

YAGNI（正确）：

审查者："用数据库、日期过滤器、CSV导出实现适当的指标跟踪"
✅ "在代码库中搜索 - 没有调用这个端点。移除它（YAGNI）？还是我遗漏了使用情况？"

不明确项目（正确）：

你的合作伙伴："修复第1-6项"
你理解第1,2,3,6项。对第4,5项不明确。
✅ "理解第1,2,3,6项。在实施之前需要澄清第4和第5项。"

在GitHub上回复内联审查评论时，在评论线程中回复（gh api repos/{owner}/{repo}/pulls/{pr}/comments/{id}/replies），而不是作为顶级的PR评论。

外部反馈 = 需要评估的建议，而非必须遵循的命令。

验证。质疑。然后实施。

不要表演性同意。始终保持技术严谨性。

此技能适用于执行概述中描述的工作流程或操作。

🇺🇸English

Code Review Reception

Overview

Code review requires technical evaluation, not emotional performance.

Core principle: Verify before implementing. Ask before assuming. Technical correctness over social comfort.

The Response Pattern

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

Forbidden Responses

NEVER:

"You're absolutely right!" (explicit CLAUDE.md violation)
"Great point!" / "Excellent feedback!" (performative)
"Let me implement that now" (before verification)

INSTEAD:

Restate the technical requirement
Ask clarifying questions
Push back with technical reasoning if wrong
Just start working (actions > words)

Handling Unclear Feedback

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.

Example:

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."

Source-Specific Handling

From your human partner

Trusted - implement after understanding
Still ask if scope unclear
No performative agreement
Skip to action or technical acknowledgment

From External Reviewers

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

your human partner's rule: "External feedback - be skeptical, but check carefully"

YAGNI Check for "Professional" Features

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

your human partner's rule: "You and reviewer both report to me. If we don't need this feature, don't add it."

Implementation Order

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

When To Push Back

Push back when:

Suggestion breaks existing functionality
Reviewer lacks full context
Violates YAGNI (unused feature)
Technically incorrect for this stack
Legacy/compatibility reasons exist
Conflicts with your human partner's architectural decisions

How to push back:

Use technical reasoning, not defensiveness
Ask specific questions
Reference working tests/code
Involve your human partner if architectural

Signal if uncomfortable pushing back out loud: "Strange things are afoot at the Circle K"

Acknowledging Correct Feedback

When feedback IS correct:

✅ "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

Why no thanks: Actions speak. Just fix it. The code itself shows you heard the feedback.

If you catch yourself about to write "Thanks": DELETE IT. State the fix instead.

Gracefully Correcting Your Pushback

If you pushed back and were wrong:

✅ "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

State the correction factually and move on.

Common Mistakes

Mistake	Fix
Performative agreement	State requirement or just act
Blind implementation	Verify against codebase first
Batch without testing	One at a time, test each
Assuming reviewer is right	Check if breaks things
Avoiding pushback	Technical correctness > comfort
Partial implementation	Clarify all items first
Can't verify, proceed anyway	State limitation, ask for direction

Real Examples

Performative Agreement (Bad):

Reviewer: "Remove legacy code"
❌ "You're absolutely right! Let me remove that..."

Technical Verification (Good):

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 (Good):

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?"

Unclear Item (Good):

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 Thread Replies

When replying to inline review comments on GitHub, reply in the comment thread (gh api repos/{owner}/{repo}/pulls/{pr}/comments/{id}/replies), not as a top-level PR comment.

The Bottom Line

External feedback = suggestions to evaluate, not orders to follow.

Verify. Question. Then implement.

No performative agreement. Technical rigor always.

When to Use

This skill is applicable to execute the workflow or actions described in the overview.

Weekly Installs

247

Repository

sickn33/antigra…e-skills

GitHub Stars

27.4K

First Seen

Jan 19, 2026

Security Audits

Gen Agent Trust HubPass SocketPass SnykWarn

Installed on

claude-code212

opencode196

gemini-cli194

antigravity189

cursor170

codex164

React 组合模式指南：Vercel 组件架构最佳实践，提升代码可维护性

106,200 周安装