القائمة
接收审查反馈。当收到代码审查反馈需要评估和实施，或提到"审查反馈""PR comment""修改意见"
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
结构化脑暴——发散探索 + 收敛评估。当想法模糊、面临开放性问题或需要方案对比，或提到"脑暴""想法""方案对比""怎么办"
恢复保存的工作上下文。当新 session 需要继续之前的工作，或提到"恢复""restore""继续上次"
保存工作上下文。当需要保存当前工作状态供后续 session 恢复，或提到"保存""save""checkpoint""挂起"
架构决策记录（ADR）。当面临技术选型、架构决策、方案取舍需要记录，或提到"ADR""决策记录""为什么这样做"
发布或导出检查 → Go/No-Go → 归档。当审查通过后需要上线或交付最终产物，或提到"发布""上线""ship""Go/No-Go"
合并 PR → 等待 CI → 验证生产。当 PR 已创建需要合并到主分支并验证部署，或提到"合并""merge""PR""land"
| name | verify-workflow-receiving-review |
| description | 接收审查反馈。当收到代码审查反馈需要评估和实施，或提到"审查反馈""PR comment""修改意见" |
/build 修复docs/features/YYYYMMDD-<name>/04-review.md（反馈响应部分） → build-workflow-execute（修复实施）完整阅读所有反馈，不做任何反应。不要边读边改。记录反馈条目数量。
用自己的话重述每条反馈的要求。复述不出来 = 没理解 → 提问澄清。每条不明确的反馈单独提问。
对照代码库验证反馈：对应代码存在吗？描述的现象真实存在吗？引用的上下文完整吗？事实不成立 → 记录证据，准备技术性回应。
对照代码库已有模式评估。考虑执行约束（性能、兼容性、迁移成本）和实施风险。给出判断：采纳 / 反驳 / 部分采纳。
采纳：说明理解和技术依据，不是空洞附和。反驳：事实 + 数据 + 替代方案。每条反馈一条回应。
按实施顺序排列，一次处理一条，每条处理后跑测试。测试失败 → 回退该条修改，重新评估。
trusted human partner： 理解后直接实施。仍需 Step 1-2。不理解的部分仍然要提问。
外部 reviewer： 需通过 5 点验证清单：事实准确？上下文完整？约束执行？YAGNI 检查？实施成本合理？
reviewer 建议"properly implement"或"add abstraction"时，先 grep 确认真实使用场景：1 个 = 不抽象，2 个 = 看风格，3+ 个 = 抽象合理。没有第三个使用场景 = 不抽象。
何时反驳： 有技术证据、有量化影响、违反代码库已有模式且无充分理由。
如何反驳： 事实 + 数据 + 替代方案。例："这个改动增加 ~200ms 延迟（基准 X ms），替代方案是 Y，因为[理由]。"
如何纠正反驳： 直接说"我之前的反驳不成立，因为..."，不找借口，立即切换实施模式。
| 禁止说辞 | 为什么禁止 |
|---|---|
| "You're absolutely right!" | 空洞同意，无技术分析 |
| "Great point!" | 无分析的附和 |
| "Thanks for catching that!" | 感谢不是技术回应 |
| "I'll fix that right away" | 没评估就承诺 |
| 对所有反馈说"好的" | yes-machine 模式 |
| 沉默接受所有建议 | 放弃独立判断 |
| 说辞 | 现实 | 后果 |
|---|---|---|
| "reviewer 总是对的" | 盲目信任和盲目拒绝一样危险。 | 盲目接受 ~20% 不适用反馈，引入新问题 |
| "不能反驳 reviewer" | 有证据的反驳是贡献。 | 压制异议 → 审查退化为人情盖章 |
| "先全部改完再说" | 批量接受 = 放弃判断。 | 无法定位哪条引入新 bug，回退范围 = 全部 |
| "反馈太多了，挑着改" | 每条都读都评估，不能不读。 | 未读反馈可能含 Critical 问题 |
| "reviewer 比我懂" | reviewer 看的是 snapshot，你活在代码库里。 | 盲目执行 snapshot 判断覆盖 lived experience |
违反字面规则就是违反精神。 没有灰色地带。
| 失败场景 | 处理方式 |
|---|---|
| 实施后测试失败 | 回退该条修改，重新评估，不继续下一条 |
| 反驳后发现不成立 | 直接承认错误，切换实施模式 |
| 外部反馈事实不成立 | 记录证据，提供技术性反驳 |
| 反馈意图不明确 | 标记"待澄清"，不猜测意图 |
| 批量修改后无法定位 | 回退全部，改为逐条实施 |
docs/features/<name>/04-review.md## Review Feedback 响应
### 反馈来源
- 来源: human partner / 外部 reviewer
- 反馈条数: N 条
- 处理状态: 全部评估 / 部分待澄清
### 逐条响应
| # | 反馈摘要 | 评估结论 | 理由 | 实施状态 |
|---|---------|---------|------|---------|
| 1 | [摘要] | 采纳/反驳/部分 | [技术依据] | 已修复/已反驳 |
### 待澄清项
| # | 反馈摘要 | 不明确之处 | 状态 |
|---|---------|----------|------|
| 7 | [摘要] | [描述] | 待 reviewer 补充 |
### 实施验证
- 全部修改后测试: PASS
- 无回归: 确认