メニュー
在接收代码审查反馈时使用，尤其是在实现建议之前，如果反馈看起来不清楚或技术上可疑时使用——要求技术严谨和验证，而不是表演式认同或盲目实现
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
用于在 Git 仓库中接手带实现 plan 的实现任务，或将无 plan 的复杂需求收敛为实现 plan 后继续实现。不用于纯问答、纯研究、大型多阶段项目、用户要求跳过流程，或无 plan 的简短任务。
用于在 Git 仓库中接手带实现 plan 的实现任务，或将无 plan 的复杂需求收敛为实现 plan 后继续实现。不用于纯问答、纯研究、大型多阶段项目、用户要求跳过流程，或无 plan 的简短任务。
在接收代码审查反馈时使用，尤其是在实现建议之前，如果反馈看起来不清楚或技术上可疑时使用——要求技术严谨和验证，而不是表演式认同或盲目实现
Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes
Test-driven development with red-green-refactor loop. Use when user wants to build features or fix bugs using TDD, mentions "red-green-refactor", wants integration tests, or asks for test-first development.
| name | receiving-code-review |
| description | 在接收代码审查反馈时使用，尤其是在实现建议之前，如果反馈看起来不清楚或技术上可疑时使用——要求技术严谨和验证，而不是表演式认同或盲目实现 |
代码审查需要的是技术评估，而不是情绪表演。
收集审查结论 -> 评估审查结论并验证 -> 修复 -> 重新发起review.
核心原则： 实现前先验证。假设前先询问。技术正确性优先于社交舒适感。
当接收代码审查反馈时：
1. READ：完整阅读反馈，不急于反应
2. UNDERSTAND：用自己的话复述需求，或者提问
3. VERIFY：对照代码库真实情况进行检查
4. EVALUATE：判断这个建议对当前代码库是否技术合理
5. RESPOND：给出技术性确认，或有理由地反驳
6. IMPLEMENT：一次处理一个事项，每项都测试
当你接受的云端审查任务等不需要用户介入的场景. 你只需要按照harness的流程在完成任务后重发审查评论.
绝不要：
改为：
根据反馈内容，按照harness的流程验证它的正确性和合理性： 先收集问题的PR和代码库上下文 通过现有测试、文档、代码验证；必要时新增最小复现测试或回归测试。
如果任何一项不清楚或不明确：
停止——先不要实现任何东西
针对不清楚的问题收集相关的文档和PR上下文
原因：多个事项之间可能有关联。理解不完整 = 实现错误。
示例：
你的人类伙伴：“修复 1-6”
你理解 1、2、3、6，但不清楚 4、5。
❌ 错误：先实现 1、2、3、6，之后再问 4、5
✅ 正确：“我理解 1、2、3、6。实现前需要先澄清 4 和 5。”
实现前：
1. 收集相关的 PR 和代码库上下文
2. 验证反馈的正确性和合理性（通过现有测试、文档、代码以及新增测试）
1. 检查：对当前代码库来说技术上正确吗？
2. 检查：会破坏现有功能吗？
3. 检查：当前实现是否有存在理由？
4. 检查：是否适用于所有平台 / 版本？
5. 检查：审查者是否理解完整上下文？
3. 重新定位评估是否需要修复
修复原则：
在以下情况下并不修复对应的问题：
* 建议会破坏现有功能且超出pr任务边界
* 审查者缺少完整上下文
* 违反 YAGNI：未使用的功能
* 对当前技术栈来说技术上不正确
* 存在遗留兼容性原因
* 与人类伙伴的架构决策冲突
除去上述情况,其他修复原则：
- P0 / P1：成立则必须修复。
- P2 / P3：仅在以下情况修复：
- 低成本、低风险，且不扩大当前 PR 边界；
- 属于明显异味、噪音、拼写、无效导入、死代码等清理；
- 已阻塞当前 PR 执行或验证；
- 与当前修改区域强相关，不修会明显降低当前 PR 质量。
其他问题默认不修复，记录到下一次审查评论中。
**如何反驳：**
* 使用技术理由，而不是防御性表达
* 提出具体问题
* 引用已有测试 / 代码
* 如果属于架构问题，让人类伙伴介入
如果建议看起来是错的：
用代码、测试或明确逻辑反证并下次请求审查评论中标注出来.
如果无法轻易验证：
明确说明：“没有 [X] 我无法验证这一点。应该 [调查 / 询问 / 继续] 吗？”
如果与人类伙伴此前的决策冲突：
停止，并先和人类伙伴讨论
你的规则： “外部反馈——保持怀疑，但认真检查。”
如果审查者建议“正确实现”某个功能：
grep 代码库，检查实际使用情况
如果没有使用：
“这个 endpoint 没有被调用。是否应该删除它（YAGNI）？”
如果有使用：
再正确实现它
你的人类伙伴的规则： “你和审查者都向我负责。如果我们不需要这个功能，就不要添加它。”
对于多项反馈：
1. 先澄清所有不清楚的内容
2. 然后按照P级别和修复原则逐项处理
3. 每个修复都单独测试
4. 验证没有引入回归问题
| 错误 | 修正 |
|---|---|
| 表演式认同 | 陈述需求，或直接行动 |
| 盲目实现 | 先对照代码库验证 |
| 批量修改但不测试 | 一次一个，逐项测试 |
| 假设审查者一定正确 | 检查是否会破坏现有行为 |
| 避免反驳 | 技术正确性优先于舒适感 |
| 部分实现 | 先澄清所有事项 |
| 无法验证但仍继续 | 说明限制，并请求方向 |
表演式认同，坏例子：
Reviewer：“删除 legacy code”
❌ “你说得太对了！我来删除……”
技术验证，好例子：
Reviewer：“删除 legacy code”
✅ “检查中……build target 是 10.15+，这个 API 需要 13+。为了向后兼容仍需要 legacy。当前实现的 bundle ID 错了——是修复它，还是放弃 pre-13 支持？”
YAGNI，好例子：
Reviewer：“实现完整的 metrics tracking，包括数据库、日期过滤、CSV 导出”
✅ “已 grep 代码库——没有任何地方调用这个 endpoint。是否删除它（YAGNI）？还是我漏掉了某个使用点？”
事项不清楚，好例子：
Reviewer：“修复 1-6”
你理解 1、2、3、6，但不清楚 4、5。
✅ “理解 1、2、3、6。实现前需要先澄清 4 和 5。”
一轮的审查修复后,按照pr-review-comment.md模板撰写审查评论，直接回复在 GitHub PR 顶级线程中从而进入下一轮的审查。
外部反馈 = 需要评估的建议，不是必须执行的命令。
验证。质疑。然后实现。
不要表演式认同。始终保持技术严谨。