关于 skill-review-response
Receiving Code Review 是面向处理代码审查意见的开发者的 Codex CLI 技能。它要求先结合代码库和需求核实每条建议，再决定回应或修改，并验证已实施的修复。
主要功能
- 01结合实际代码评估反馈
- 02复述并评判每条建议
- 03基于证据进行技术性反驳
- 04逐项实施审查意见
- 05验证修改并复查原始反馈
适用场景
- 01判断报告的问题是否适用
- 02回应技术上不成立的建议
- 03处理相互冲突的审查意见
- 04确认修复是否解决问题根源
安装
复制下面的命令，在终端中运行。
$
npx skills add https:/安装后在 Claude Code 中输入/skill-review-response确认已加载。
附带文件agents/openai.yaml
详细介绍
宿主：Codex CLI — 此技能最初为 Claude Code 设计，后适配至 Codex。 交叉引用命令在 Codex 中使用已安装的技能名称，而非
/octo:*斜杠命令。 使用当前 Codex shell 和子 Agent 工具。除非当前会话已提供相应功能，否则不要声称某个提供方、模型或宿主子 Agent 可用。 宿主工具的对应项请参见skills/blocks/codex-host-adapter.md。
接收代码审查意见
核心原则
代码审查需要进行技术评估，而不是表演式认同。
绝不要盲目采纳审查意见。 做出任何更改之前，先确认它是否适用于此代码库。
响应模式
WHEN receiving code review feedback:
1. READ — Complete feedback without reacting
2. RESTATE — Summarize the requirement in your own words
3. VERIFY — Check against actual codebase state
4. EVALUATE — Is this technically sound for THIS context?
5. RESPOND — Technical acknowledgment OR reasoned pushback
6. IMPLEMENT — One item at a time, verify each change
禁止的回复
绝不要说：
- “你说得完全正确！”（未经核实）
- “发现得真好！”（尚未确认这确实是个问题）
- “我马上修复！”（尚未评估是否需要修复）
- “完成了！”（尚未运行验证——请参见 skill-verification-gate）
这些属于社交表演，而非技术评估。 它们会导致：
- 实施错误的建议
- 为了“修复”并非问题的问题而引入 bug
- 在伪装成 bug 的风格偏好上浪费时间
评估清单
针对每条反馈：
| 问题 | 如果是 | 如果否 |
|---|---|---|
| 问题是否真实存在？（在代码中核实） | 继续评估 | 提供证据并提出异议 |
| 建议的修复在这里是否有效？ | 继续评估 | 提出替代方案 |
| 修复是否会导致其他问题？ | 一并修复，或提出异议 | 实施修复 |
| 这是风格偏好还是真正的问题？ | 表示已知悉，降低优先级 | 修复 |
| 这是否是之前已经考虑并否决的方案？ | 说明权衡 | 实施 |
如何提出异议
当反馈有误或不适用时：
> Reviewer: "This function should handle null input"
>
> Response: "Checked — this function is only called from `processUser()`
> (line 47) which validates non-null before dispatch. Adding null handling
> here would be dead code. The caller contract guarantees non-null."
请说明：
- 你检查了什么
- 为什么该建议不适用
- 证据（行号、调用位置、测试）
多提供方审查背景
在 Claude Octopus 工作流中，审查反馈来自多个来源：
- Codex 审查 — 倾向于采用企业级模式，可能过度设计
- Antigravity 审查 — 倾向于遵循生态惯例，可能建议不必要的依赖
- Claude 审查 — 倾向于追求简洁，可能对错误处理设计不足
- Sonnet 审查 — 倾向于全面细致，可能指出优先级较低的问题
当不同提供方意见不一致时：
- 检查哪个提供方的建议符合代码库的实际惯例
- 代码库现有模式优先于任何提供方的偏好
- 如果两个提供方指出同一个问题，它很可能确实存在
处理反馈循环
当审查者指出问题，而你修复了它时：
- 进行修复
- 运行验证（skill-verification-gate）——证明修复有效
- 重新阅读原始反馈——你解决了根本原因，还是只处理了表面症状？
- 如果审查者再次审查后发现新问题，这是正常的——不要沮丧
- 每轮的问题都应该减少，而不是换成别的问题
如果同一个问题反复出现：
- 你修复的是表面症状，而非根本原因
- 停下来，从头重新阅读反馈
- 如果问题含糊不清，请审查者进一步说明
审查反馈与需求冲突时
如果审查者提出的建议与规范/需求矛盾：
- 明确指出冲突
- 检查规范是否有误（确实有可能）
- 如果规范正确：按规范实施，并记录审查者的顾虑以供日后考虑
- 如果规范有误：更改任何内容之前先向用户指出
需求优先于审查建议。用户意图优先于两者。
评论
支持 Markdown