| name | fix-review |
| description | 修复 Code Review 发现的问题，支持按严重级别分级处理（block/all/discuss），架构视角修复而非补丁式 Patch。当需要处理 /code-review 报告中的问题时使用。 |
| argument-hint | <block|all|discuss> [#PR-N | @文件路径 | 留空用当前上下文] |
| model | opus |
Fix Review — Code Review 问题修复
处理 /code-review 输出的问题报告。核心原则：验证先行 + 全局修复策略 + 禁止逐个打补丁。
Step 0：解析参数
修复模式（第一个 token）：
| 参数 | 修复范围 | 说明 |
|---|
block | 仅 🔴 问题 | 阻塞合并的必须修复项（默认） |
all | 🔴 + 🟡 | 阻塞问题 + 建议改进 |
discuss | 架构讨论项 | interview 模式讨论方案，不直接改代码 |
报告来源（剩余部分）：
| 格式 | 说明 |
|---|
#PR-<number> | 从 GitHub PR review comments 获取 |
@<文件路径> | 从指定文件读取 |
| 留空 | 从当前对话上下文查找 |
Step 1：定位审查报告
-
根据报告来源定位：
#PR-N：gh api repos/{owner}/{repo}/pulls/N/comments 获取 PR comments@<path>：直接读取文件- 留空：查找当前对话中
/code-review 的输出
- 均未找到 → 请求用户提供报告或运行
/code-review
-
解析报告结构（对应 /code-review 输出格式）：
- 🔴 必须修复：编号 + 文件:行号 + 问题描述 + 修复建议
- 🟡 建议改进：同上
- 🟢 值得肯定：无需处理
- 测试覆盖评估：可能含需补充的测试用例
-
根据修复模式筛选目标问题集合。
Step 2：进入 Plan 模式
使用 EnterPlanMode。所有验证和方案设计在 Plan 模式内完成，审批后才可编码。
Step 3：验证问题真实性（对每个问题必做）
Code Review 可能误判，修复不存在的问题比不修复真实问题更危险。
3.1 读取原始代码
读取报告指出的文件和行号的完整上下文（至少前后 30 行）。跨模块问题须追踪完整调用链。
3.2 验证清单
3.3 验证结论
| 结论 | 后续行动 |
|---|
| ✅ 确认存在 | 进入 Step 4 修复 |
| ⚠️ 部分成立 | 修正范围后进入 Step 4 |
| ❌ 误判 | 跳过，报告中说明 |
| 🔄 已修复 | 跳过，报告中确认 |
| 🔼 上游问题 | 输出 Bug Report，不修改上游 |
输出验证摘要（每个问题一行），等待用户确认后继续。
Step 4：设计修复策略（针对确认的问题）
禁止逐个问题打补丁，必须先建立全局修复视图。
4.1 问题归类与关联分析
- 同文件合并：一次修改中统一解决
- 同模块归组：优先一起处理
- 因果关系：某些问题可能是其他问题的症状
- 修改顺序：先底层（协议/DTO）→ 中间层（服务/工具）→ 上层（测试/UI）
4.2 方案设计原则
- 根因修复：不做 patch，修正问题根源
- 最小侵入：不引入新的架构债务
- 全局一致：搜索类似场景的既有实现作为参考
- 副作用评估：列出修改可能影响的其他文件
- 协议兼容：涉及协议类型的修改需对照协议规范确认
项目特有架构原则参见 {baseDir}/resources/<project>.md。
4.3 输出修复计划
按 Group 归组输出，含关联影响和修改文件清单。使用 ExitPlanMode 提交计划等待审批。
Step 5：执行修复（审批后）
5.1 修改前
- 读取待修改文件的完整内容（不只看 diff）
- 搜索项目中类似实现作为风格参考
- Grep 确认没有遗漏的关联引用
5.2 修改执行
项目特有编码规范和验证命令参见 {baseDir}/resources/<project>.md。
5.3 修改后立即验证
每组修改完成后运行项目对应的验证命令。验证失败须修复后重新验证，不可跳过。
Step 6：讨论模式（仅 discuss 参数）
不执行代码修改，进入 interview 模式：
- 逐条讨论架构决策项，提出 2-3 个方案 + trade-off 分析
- 使用 AskUserQuestion 与用户深入讨论
- 达成共识后：需要改代码 → 按 Step 4-5 执行；暂不修改 → 记录决策理由
- 涉及协议变更 → 引导走
/add-feature 协议先行流程
Step 7：输出修复总结
## 验证结果
| 编号 | 问题 | 验证结论 |
|------|------|---------|
| 🔴1 | xxx | ✅ 已修复 |
| 🔴2 | xxx | ❌ 误判跳过 |
## 修改文件清单
| 文件 | 修改类型 | 关联问题 |
|------|---------|---------|
## 验证状态
- [ ] lint / 类型检查通过
- [ ] 涉及模块的测试通过
- [ ] 全量测试通过
## 备注
- [误判说明] [协议兼容性确认] [上游 Bug Report] [遗留讨论项]
反模式（严格禁止）
- 不验证就修复 — 不确认问题是否真实存在就改代码
- 逐个打补丁 — 不做全局分析，头痛医头脚痛医脚
- 为修复而修复 — 问题不存在也硬改交差
- 引入新问题 — 修复过程中引入新的类型错误/硬编码/分层违规
- 忽略关联影响 — 改了底层不更新下游引用
- 跳过验证 — 改完不运行 lint/typecheck/test
- discuss 模式直接改代码 — 讨论项需要共识，不能擅自决定
