القائمة
Use when receiving feedback from code-reviewer subagent or human reviewer
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Use when a feature, bugfix, or refactoring step is completed and needs review, or before merging to main, or when user says "review", "审查", "帮我看看代码"
Use when receiving an ambiguous feature request, when scope is unclear, or before writing any plan
Use after verification-before-completion passes and code review is clean, to close out the development branch
Use when executing git commit, creating or naming branches, writing PR titles/descriptions, or asking about commit message format, branch naming, or version numbering in this project
Use when writing or reviewing .ets/.ts files in this project, or when seeing any, unknown, obj['key'] index access, destructuring assignment, var declarations,
Use when user asks to create a version release ticket, says "帮我建个发版任务", "建个 Jira", "创建发版单", or needs to track an SDK release in Jira
| name | receiving-code-review |
| description | Use when receiving feedback from code-reviewer subagent or human reviewer |
Type: Technique | Discipline: Rigid
收到 code-reviewer subagent 或人类 reviewer 的反馈后，按本技能规范处理。核心原则：验证先于实施，澄清先于假设，技术正确性高于社交舒适度。
收到审查反馈
↓
1. READ：完整读完所有反馈，不急于行动
2. UNDERSTAND：用自己的话复述每条要求（或提问）
3. VERIFY：对照代码库现状核实
4. EVALUATE：对本项目是否技术合理？
5. RESPOND：技术性确认或有理据的 push back
6. IMPLEMENT：逐条修复，每条单独测试
如果反馈中任何一项不明确：
→ 全部暂停，不实施任何一项
→ 先对不明确的项提问澄清
→ 澄清完毕后再开始实施
原因：各项可能相互关联，部分理解 = 错误实施。
示例：
reviewer 返回 6 条问题，你理解 1、2、3、6，不确定 4、5。
❌ 错误：先改 1、2、3、6，回头再问 4、5
✅ 正确："第 1、2、3、6 条已理解。第 4 条和第 5 条需要澄清：
- 第 4 条提到 'session 边界处理'，是指 onForeground 还是 VISIT 事件？
- 第 5 条 '协议对齐'，具体是哪个字段？"
实施前逐条验证：
1. 对本代码库技术上正确吗？
2. 会破坏已有功能吗？
3. 当前实现是否有特殊原因？
4. 是否适用于所有产品线（SaaS/NewSaaS/CDP）？
5. reviewer 是否掌握了完整上下文？
如果建议有误：
→ 用技术理由 push back，不盲目接受
如果无法验证：
→ 明确说"我无法验证这一点，需要 [X] 才能确认。是否继续？"
如果与用户之前的架构决策冲突：
→ 暂停，先与用户确认
当 reviewer 建议"实现得更完善"时：
→ 先 grep 代码库确认是否有实际调用
如果没有调用："这个接口当前没有调用方，是否需要实现？（YAGNI）"
如果有调用：按建议实现
绝不说：
应该说：
file:line 修复。"应该 push back 的情况：
如何 push back：
✅ "你是对的——我验证了 [X]，确实 [Y]。正在修复。"
❌ 长篇道歉
❌ 解释为什么当时 push back
陈述事实，继续工作。
多条反馈的处理顺序：
1. 先澄清所有不明确的项（STOP-ASK）
2. 按以下优先级实施：
a. Critical（阻塞项：崩溃、数据丢失、隐私泄露）
b. 简单修复（拼写、导入、格式）
c. 复杂修复（重构、逻辑变更）
3. 每条修复后单独验证
4. 全部完成后确认无回归
| 错误 | 纠正 |
|---|---|
| 表演式认同 | 直接修复或给出技术性回应 |
| 不验证就实施 | 先对照代码库核实 |
| 批量修改不测试 | 逐条修复，逐条验证 |
| 假定 reviewer 一定对 | 检查是否会破坏现有功能 |
| 回避 push back | 技术正确性 > 社交舒适度 |
| 部分理解就开始改 | STOP-ASK，先澄清所有不明确项 |
| 无法验证仍然继续 | 明确说出局限，请求指导 |
| Excuse | Reality |
|---|---|
| "reviewer 说的有理，全盘接受避免冲突" | 表演式认同是失职；正确的反应是修复或给技术反驳 |
| "reviewer 这条我觉得不对，忽略就行" | 必须 push back 并给技术理由，不是沉默不处理 |
| "改完了不用重新 dispatch，reviewer 不会再挑出新问题" | Critical/Important 修完必须重新 review，不可自判 |
| "先改 Critical，Important 合并前再说" | Important 也阻塞合并，只有 Suggestion 可延后 |
| "一次把所有意见全改完再验证" | 批量修改后一个点崩了定位困难，逐条修复逐条验证 |
| "部分听懂了就开始改" | 不明确项必须 STOP-ASK，改错的成本高于问一句 |
| "我改得很小，不用重跑 verify" | 任何修改后 verify 都要重跑——这是 verification-before-completion 的不变量 |
| "改完 reviewer 一定会通过，不用重新 dispatch 了" | Critical/Important 修完必须重新 review，自判=赌博 |
反馈项全部实施完成后，必须按以下顺序走完回路，不得自行判定"改好了"：
sdk-code-review 的同一 reviewer 角色verification-before-completion 重跑（修复可能破坏既有验证，不重跑就是赌博）finishing-a-development-branch）sdk-code-review 的 reviewer subagent 或人类 reviewer 反馈