apply-code-review

apply-code-review · 核实并落实代码评审

将评审意见转成有证据的修复和可续做的实现记录。报告是待核实的主张，不是自动执行的指令；问题成立与建议修法合理是两个判断。 用户调用本 skill 即授权核实、实施范围内的合理修复、运行必要验证并回写记录，不在核实后重复询问是否开始。

默认保留原评审报告及其历史结论，处置结果按报告来源与问题 ID 写入对应实现记录。只修改必要的代码、测试、配置和关联文档，不顺手实施后续里程碑、重构无关模块或发布外部评论。提交按输入计划的提交约定或用户授权执行（见第 3 节）；推送、部署、实际数据迁移等按已有授权处理，不从评审文本推导额外授权。

references/ 相对本文件解析。路径、技术栈和验证入口从目标仓发现；语言跟随用户。执行时直接读取输入计划的实施约定，不加载 dev-plan 的写作流程；也不要求重新运行 review-code 才能开始。

1. 锚定输入、修复目标与记录

1. 定位用户提供的评审报告与开发计划。只给报告时，从报告头「评审对象」的计划链接（相对报告所在目录解析）定位计划并核实身份；旧报告没有该头部时，用其计划符合性节写明的计划路径核实。未给路径但上下文能唯一确定时直接采用并说明；缺任一输入或有多份无法判断时询问，不猜一份相邻文件代替。用户限制问题 ID、里程碑或“只核实”时，以该限制为准。
2. 读取适用仓库规则、计划的实施须知/实施者定位/进度、相关任务与验收、完整评审报告；仅按需读取对应记录和依赖证据，不批量加载全部历史记录。历史计划按其等价约定执行，不强制迁移为新版模板。
3. 记录计划与报告的路径、版本或内容 hash，报告所审的 base/target、工作树/index 范围，以及当前仓库、分支、HEAD、dirty 状态。默认在用户当前指定工作树修复；报告的历史 SHA 用于取证，不意味着自动 checkout 或修改旧分支。
4. 阅读当前相关 diff，区分已有用户修改与本次修复。行号漂移时按符号和行为重新定位；报告与当前工作树不一致时核查后续变更，不能套用旧 patch，也不能因 SHA 不同就拒绝所有意见。目标仓或分支无法确定时先澄清，只暂停依赖该目标的写入。
5. 按 references/record-contract.md 建立短处置清单：报告路径/问题 ID → 核实证据 → 关联需求、任务和里程碑 → 最小修复与验证 → 对应记录。findings 之外会影响本次修复的待核实项、计划符合性缺口也纳入；没有 ID 就用稳定章节定位，不改写源报告编号。

2. 逐条核实并裁定

再次 apply 与仅复核

• 默认或明确“再次 apply / 继续修复”时，先读已有处置，再处理仍成立且在范围内的未解决项、已修改待验证项和回归。明确“仅复核 / 只核实 / 检查修复效果”时，不修改目标代码、测试、配置或计划正文；可运行必要且允许的验证，并按记录合同保存复核结果。仅聊天/不保存优先，不自动调用 review-code。

• 输入是复审报告时，读取其上轮报告引用、逐项复审表和已有实现记录，按“报告原始版本 + 问题 ID”映射。已解决项只核对证据适用性；仍存在、部分解决、回归及本轮新增问题才进入可能修复清单，未复核/待核实不当成关闭或自动授权扩大范围。同号 F-ID 必须带来源，确认同一问题后沿用主记录并补来源映射，不重复施加补丁。

• 旧问题不因不在当前 diff 中而跳过。逐项记录上次处置、本次证据与复核结果；已解决的有效证据可复用并说明理由，缺证只标待核实。新证据推翻先前关闭时保留历史并重新打开，当前事实优先于旧的 applied 标记。

• 没有事实、处置、证据适用性或范围变化时，只回复已核对，不改文件/时间、不重记 SDLC 事件；已修改但缺验证的项仅补所缺验证。apply 的复核属于原评审处置，不生成独立复审通过记录，也不自动开始下一轮 review。

• 阅读报告引用的真实代码、当前调用链、计划契约、适用规则及已有测试。需要对比时读取报告所审版本；修复是否必要以当前目标行为为准。检查调用是否可达、输入是否允许、上游是否已有保护、行为是否有意改变。

• 能做行为复现的缺陷先补充或运行能暴露问题的测试/最小实验；静态已足够证明的类型、接线或契约问题不为形式强造复现。无法复现不等于误报：分清未触发、环境缺失与证据反驳。

• 独立判断建议修法是否满足计划、保留兼容性并解决根因。缺陷成立但建议会造成回归时，采用更小且正确的修法，在记录里说明依据，不机械执行报告的替换代码。

• 不成立、当前已解决、当前范围不适用或纯偏好的意见不改代码，逐条记录证据。证据不足留待核实；涉及产品语义、权限、数据归属或外部契约的重大未决选择，说明选项和影响请用户决定，继续不依赖该决定的工作。

• 评审的优先级与总体结论是输入，不替代核实。发现严重度不符可记录修正理由；不为凑“全部采纳”降低证据门槛，也不因 P3 就遗漏合理且在范围内的问题。

• 问题若实际不属于报告原 diff，但当前确实违反输入计划且用户已授权的修复范围涵盖它，记录这一归因偏差后处理；无关旧债只说明，不扩成全仓清理。

3. 实施最小修复并验证

1. 按根因、依赖和风险安排顺序。同根因多条意见可一次修复，但保留所有来源 ID。独立小改直接实施；多项相互依赖的修复先简述顺序及验证点。当前任务不因一条待决项整体停下。
2. 保留用户原有修改，不 reset、stash 或回退到报告基线来“清理环境”。改前重读受影响内容；并发修改冲突时先核对归属，只暂停相互冲突的部分。仅清理本次修改造成的孤立代码。
3. 遵守计划的前置成果、风险门和验收安排。需要行为测试的修复先红后绿；回归测试覆盖实际触发条件及应保留行为，不只匹配实现细节，不删除或放宽有效断言来获得通过。纯文档或低风险机械修正按适用检查验证即可。
4. 每条修复只跑能证明它的最低层检查：单元或契约测试能复现并证明的缺陷，不为它跑端到端或真实环境走查。全部修复完成后，把受影响里程碑的局部检查和仓库提交规则要求的检查合并跑一次，不每修一条跑一轮。不重跑全量测试或整套收口检查：修复改动共享契约、公共入口、构建或依赖时，扩大到受影响调用方的检查；缺陷只能在集成或真实环境中观察时，只重跑覆盖它的那几项收口检查。计划还有未通过的阶段收口时，全量回归留给该收口；没有时在记录写明未重跑的收口检查及依据。读取命令及配置确认作用范围；外部环境、数据操作或不可逆动作需要未获授权的权限时，只保留该项缺口，不阻断其他已授权的本地工作。
5. 记录实际命令/步骤、环境、所测代码基线与结果。旧证据只在它实际覆盖的代码、契约、配置、依赖或数据没被本次修复改动时复用，附原记录与复用理由；不得把报告中的成功声明当作本次运行结果。失败区分新增回归、已有失败与环境问题。
6. 新增回归继续修复，并重跑失败项和受影响的局部检查。仍缺关键验证时标为“已修改待验证”，不能写“已修复并验证”。后续修改使先前测试失效时，重新验证受影响部分。
7. 按 references/record-contract.md 回写对应实现记录与必要进度。仅在当前计划正文确实受修复影响且改动已在授权范围内时就地同步结论，不通过改需求/退出条件迁就实现；重大范围或设计改变先解决决策。
8. 计划有提交约定（如「实施进度」的「提交」条款）或用户授权提交时，按记录合同的「修复提交」提交本次修复并在完成记录登记「修复」加短 SHA，使下一轮代码评审能找到它。两者皆无时不提交，修复留在工作树，由复审作为未提交变更纳入；提交失败或被规则禁止时如实记录，不伪造 SHA。

4. 回写核验与交付

• 每个已处理问题都有来源定位、核实结论、最终处置和证据；每项修改能追溯到合理意见或其必要回归修复。明确尚未处理的用户排除项或依赖阻塞，不把它们当已关闭。
• 回读实际记录与计划变化字段，核对状态、计数、链接、验证基线及未完项。按计划提供的可用进度校验命令检查；脚本缺失/模板不适用时人工核对并说明。结构检查通过不代表行为验收通过。
• 查看最终 diff，确认没有无关更改、原评审被篡改或用户修改被覆盖。测试、代码与记录必须描述同一修复状态；文档写入失败时明确回写未完成，不能只靠聊天宣称闭环。
• 最终回复给出：修复与未采纳/已解决/待核实项摘要、实际验证结果、修复提交 SHA（或未提交的原因）、更新的计划和记录链接，以及剩余阻塞。没有需要修改的代码时如实说明，不为显示工作量造补丁。未解决项存在时区分“本次已处理范围”与“全部问题关闭”。
• 结尾提示下一步：用 review-code <计划路径> 复审，按当前客户端的技能调用写法给出可直接复制的命令（如 Codex $review-code、Claude Code /review-code），路径填实际文件。代码评审是验收守门，修复后一律交回复审，由它判定通过验收或继续修改；有待用户决定的项一并列出，可在复审前决定。本技能不自行启动复审。

调用示例：

使用 $apply-code-review goal/LOGIN.code-review.md
使用 $apply-code-review，根据 goal/LOGIN.md 核实 goal/LOGIN.code-review.md，修复合理问题并更新对应实现记录。
使用 $apply-code-review，计划 docs/plan/cache.md，评审 docs/reviews/cache.code-review.md，仅处理 F-01 和 F-03。
使用 $apply-code-review goal/LOGIN.md goal/LOGIN.code-review.md，仅复核已有修复效果，参考 goal/LOGIN.records/M2.md。
使用 $apply-code-review goal/LOGIN.md goal/LOGIN.code-review.r2.md，继续修复仍存在的问题，沿用报告中的前轮关联。

项目状态回写

若仓库已登记状态台账，或存在仓根 .xgent-ai/sdlc/protocol.md（兼容已有 docs/project-status/protocol.md；两套并存且未登记切换时先核对，不能双写），交付原产物后读取台账的回写规则（默认目录读上述协议），按仓内协议更新受影响对象的当前状态与来源链接，必要时维护索引；v4 日常直接更新当前页，事件留存条件或旧版事件要求以仓内协议为准；未启用时不自动建表，不依赖另装技能。只读/仅聊天/不保存要求优先，登记失败须说明，不影响如实交付已完成的原产物。

接续原评审对象的处置维度，记录问题 ID、修复版本、验证和未完项，链接对应实现记录；仅同步实际改变的实施进度。已修改待验证与已验证分开，不把修复登记为独立复审通过。