메뉴
在接收代码审查反馈时使用，尤其是在实现建议之前，如果反馈看起来不清楚或技术上可疑时使用——要求技术严谨和验证，而不是表演式认同或盲目实现
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 顶级线程中从而进入下一轮的审查。
外部反馈 = 需要评估的建议，不是必须执行的命令。
验证。质疑。然后实现。
不要表演式认同。始终保持技术严谨。