vamdawn Ack Code Review
根据 code review 审查报告继续推进整改。这个 skill 的职责不是重新发起一次完整审查，而是消费已有审查结论，逐条做技术判断，并把应采纳的问题修到可运行、可验证的真实实现状态。
核心目标
完成以下闭环：
- 读取审查报告
- 拆分每一条 review 问题
- 判断每条是否采纳
- 对采纳的问题做增量修复
- 对不采纳的问题给出明确技术依据
- 输出固定结构的整改结果
适用场景
优先在这些场景使用：
- 用户要求“根据 code review 修复”
- 用户要求“按审查报告继续整改”
- 用户给了 review Markdown，希望决定哪些意见采纳并落地
- 用户强调当前代码已经修过一部分，希望在现有基础上持续修复
- 用户要求按实现方案和 review 依据继续改造，而不是自由发挥
如果用户要的是“重新做一次审查”，不要使用这个 skill，应切换到发起审查类 skill。
输入解析
优先读取 $ARGUMENTS：
- 若
$ARGUMENTS是文件路径，直接读取该文件 - 若
$ARGUMENTS是一段 Markdown 或文本，把它当作审查报告内容 - 若
$ARGUMENTS为空，先在仓库里推测候选审查报告，再向用户确认
当用户没有提供审查报告时，不要直接假定某个文件就是目标。优先按文件语义推测候选项：
- 最近新增或最近修改、文件名中包含
review、code-review、findings、audit的 Markdown 文件 - 审查报告、整改记录、审计结论等语义接近的 Markdown 或文本文件
- 若仓库中存在常见目录，如
docs/reviews/、reviews/、review/，再把这些目录作为补充候选来源
推测完成后，向用户给出简短确认，例如：
我找到了候选审查报告 A/B，默认建议使用 A。请确认。
只有用户确认后再继续。
工作原则
始终遵守以下约束：
- 增量修改，不推翻重写
- 每一处改动都要能对齐实现方案或 review 依据
- 禁止用 TODO、stub、mock、空分支来占位
- 不因为复杂而跳过 review 中的问题
- 以当前代码状态为基线继续推进，不抹掉已有修复成果
- 修复后要验证，不要只停留在代码编辑完成
如果发现用户给的提示词和当前代码状态冲突，以当前仓库事实为准，并把冲突说明清楚。
Step 1. 建立整改上下文
先收集三类输入：
review_report: 审查报告本身implementation_basis: 实现方案、设计文档、需求说明、验收标准code_scope: 当前改动涉及的模块、目录、分支或 diff 范围
处理顺序：
- 先读审查报告
- 再找实现依据
- 再收敛代码范围
如果用户没有显式给实现方案，不要立刻停止。先从以下来源推测：
- 用户当前会话里提到的方案
- 仓库中的设计文档、计划文档、需求文档
- 审查报告中引用的目标、约束和验收要求
如果仍然找不到完整实现依据：
- 可以继续处理那些“仅依赖代码正确性就能判断”的 review 问题
- 对于明显依赖方案判断的问题，要标记为“待确认”，并在输出中说明依据不足
Step 2. 逐条拆分审查问题
把审查报告拆成原子问题，一条 issue 只表达一个可判断、可处理的点。
对每条 issue 提取：
- 编号或标题
- 原始描述
- 严重级别
- 定位信息
- 建议修改方案
- 关联的实现方案约束
如果审查报告写得比较散，主动整理成“问题列表”，不要照抄一整段模糊描述就开始改代码。
Step 3. 判断是否采纳
阅读 references/decision-rules.md 后，对每条 issue 做三选一判断：
采纳不采纳待确认
判断时必须基于证据，而不是迎合 review 语气。
采纳标准
以下情况通常应采纳：
- 审查指出了真实 bug、边界错误、漏测、风险实现
- 当前实现与方案、需求或既有架构约束不一致
- 审查指出了会影响正确性、稳定性、可维护性的问题
- 审查意见虽然表达方式不精确，但核心问题成立
不采纳标准
以下情况通常不采纳：
- 审查基于误读，代码实际上已经满足要求
- 建议与实现方案、项目架构或明确约束冲突
- 建议会引入更大破坏，而问题本身并不存在
- 审查只是一种风格偏好，且没有带来明确收益
待确认标准
只有在这类情况下才保留为 待确认：
- 缺少关键上下文，无法安全判断
- 审查意见之间互相冲突
- 是否采纳取决于业务规则，而仓库和会话里都没有证据
不要把本该自行判断的问题都推给用户。
Step 4. 先给出整改计划，再动手改代码
在真正修改文件前，先整理一份简短整改计划，至少说明：
- 本次准备采纳哪些问题
- 每个问题会改哪些模块
- 哪些问题明确不采纳，以及原因
- 哪些问题暂时待确认，以及缺少什么信息
如果改动跨度较大，优先按风险最高的问题先修。
Step 5. 执行增量修复
只对“采纳”的问题动手修改代码。
修复时遵守以下要求：
- 基于当前实现最小化改动
- 优先复用已有抽象、测试和模块边界
- 涉及多文件时，要把结构调整一次做完整
- 不留下半成品逻辑
- 如果发现某条 review 的根因比报告写得更深，要顺着根因一并修掉
如果某个问题已经被部分修复，不要覆盖式重做；在现有修复基础上补完缺口。
Step 6. 验证修复结果
完成修改后必须运行与改动直接相关的验证：
- 单元测试
- 集成测试
- lint / typecheck
- 最小可复现场景验证
按改动实际情况选择最有证明力的验证方式，不要机械全跑，也不要完全不跑。
如果验证受环境限制无法执行，明确写出未验证项和原因。
Step 7. 按固定结构输出
最终输出必须使用以下结构，且内容只保留和本次任务直接相关的信息。
1. 修改说明
- 本次解决了哪些 review 问题，逐条列出
- 每条对应实现方案中的哪部分，若没有完整方案则说明依据来自哪里
- 是否涉及结构性调整；若有，说明调整原因
- 哪些问题没有采纳，以及技术理由
- 哪些问题仍待确认，以及缺失的上下文
2. 代码修改
- 说明改动过的文件
- 概述每个文件承担的修改点
- 如果用户明确要求展示完整代码，再按文件分组给出完整可运行代码
- 默认不要在会话里粘贴超长文件全文，优先给文件路径和改动说明
3. 自检
逐条确认：
- 所有 review 问题已覆盖
- 没有占位实现
- 与实现方案一致
- 没有引入新问题
如果某一项不能打勾，必须说明原因。
冲突处理
遇到以下冲突时，不要停在表面：
- 审查报告与实现方案冲突
- 审查报告与当前代码事实冲突
- 不同审查意见相互冲突
处理方式：
- 先指出冲突点
- 再说明你采用的判断依据
- 在可确定范围内继续修复
- 把不能确定的部分单独列出，而不是整单搁置
输出风格
- 直接、克制、面向执行
- 先给结论，再给证据
- 不写无关背景铺垫
- 不把“采纳了哪些意见”说成“已经彻底完成”除非有验证证据支持
禁止事项
不要这样做：
- 把审查报告视为绝对正确，不加判断全部接受
- 看到已有部分修复就推翻重做
- 用“暂留 TODO”代替真实实现
- 因为涉及多文件或结构调整就跳过问题
- 没有验证就声称修复完成
- 在没有用户确认的情况下，擅自选择一个推测出来的审查报告