fix

.opencode/skills/bug-fix/SKILL.md

@@ -0,0 +1,201 @@
+---
+name: bug-fix
+description: Bug诊断与修复技能 - 强调交互式确认和影响分析
+tags:
+  - bug-fix
+  - debugging
+  - troubleshooting
+  - interactive
+version: 1.0.1
+---
+
+# Bug修复技能
+
+## 技能概述
+
+专门用于诊断和修复项目中的bug，强调谨慎的分析流程和充分的交互式确认，确保修复的准确性和完整性，避免引入新的问题或破坏现有功能。
+
+## ⚠️ 强制交互规则（MUST FOLLOW）
+
+**遇到需要用户确认的情况时，必须立即调用 `question` 工具：**
+
+❌ **禁止**："我需要向用户确认..."、"请用户回答..."、"在Plan模式下建议先询问..."  
+✅ **必须**：直接调用工具，不要描述或延迟
+
+**调用格式**：
+```javascript
+question({
+  header: "问题确认",
+  questions: [{
+    question: "具体触发场景是什么？",
+    options: ["新增时", "修改时", "批量导入时", "定时任务时", "其他"]
+  }]
+})
+```
+
+**规则**：
+- 每次最多 **3个问题**
+- 每个问题 **3-6个选项**（穷举常见情况 + "其他"兜底）
+- 用户通过**上下键导航**选择
+- 适用于**所有模式**（Build/Plan）
+
+## 执行原则
+
+### 1. 充分理解问题（必要时交互确认）
+
+**触发条件**：
+- 用户对bug的描述含糊不清
+- 问题复现步骤不完整
+- 预期行为与实际行为表述存在歧义
+- 涉及多个可能的问题根因
+
+**执行策略**：
+- ✅ **立即调用 `question` 工具**（不要描述，直接执行）
+- ✅ **暂停其他操作**，不要基于假设进行修复
+- ✅ 澄清：错误现象、触发条件、预期行为、是否有日志
+
+### 2. 风险评估与影响分析（必要时交互确认）
+
+**触发条件**：
+- 发现潜在的边界情况用户未提及
+- 代码修改可能影响其他功能模块
+- 存在多种修复方案，各有利弊
+- 发现可能的性能、安全或兼容性隐患
+
+**执行策略**：
+- ✅ 代码分析后，**不要直接修改代码**
+- ✅ 报告潜在问题：影响范围、边界情况、测试场景、数据迁移需求
+- ✅ **使用 `question` 工具**让用户选择方案或确认风险
+
+### 3. 关联代码检查（必要时交互确认）
+
+**触发条件**：
+- 发现多个位置存在相似的代码逻辑
+- 修复需要同步更新多个文件
+- 存在可能依赖该bug行为的代码（反模式）
+- 发现测试用例可能基于错误行为编写
+
+**执行策略**：
+- ✅ 使用代码搜索工具查找相似逻辑和调用链
+- ✅ 报告关联代码：是否需要同步修复、依赖关系、测试更新
+- ✅ **使用 `question` 工具**让用户确认修复范围
+
+## 修复流程
+
+### 阶段1: 问题诊断
+1. 阅读用户的bug描述
+2. 定位相关代码文件（使用 semantic_search, grep_search）
+3. 分析代码逻辑和调用链
+4. **触发点1**: 如有不明确之处 → **立即调用 `question` 工具**（不要描述计划）
+
+### 阶段2: 根因分析
+1. 确定bug的根本原因
+2. 识别影响范围和边界情况
+3. **触发点2**: 发现用户未考虑的问题 → **立即调用 `question` 工具**
+
+### 阶段3: 方案设计
+1. 设计修复方案
+2. 评估方案的影响和风险
+3. 查找相似代码和依赖关系
+4. **触发点3**: 可能影响其他逻辑 → **立即调用 `question` 工具**
+
+### 阶段4: 实施修复
+1. 获得用户最终确认后执行代码修改
+2. 使用 `multi_replace_string_in_file` 批量修改
+3. 确保修改的原子性和一致性
+
+### 阶段5: 验证建议
+提示用户执行：单元测试（`dotnet test`）、手动测试场景、回归测试
+
+## 反模式与成功标准
+
+❌ **不要**在未明确理解问题的情况下猜测修复
+❌ **不要**在未评估影响范围的情况下直接修改代码
+❌ **不要**假设用户已考虑所有边界情况
+❌ **不要**在发现关联逻辑时仅修复单个位置
+❌ **不要**跳过风险通知直接实施有争议的修复方案
+❌ **不要**修改代码后不提供验证建议
+❌ **不要**描述"我会询问用户..."而不调用 `question` 工具
+❌ **不要**列出问题清单让用户自行回答
+❌ **不要**在Plan模式下说"如果用户确认..."而不执行工具调用
+
+## 成功标准
+
+✅ 用户明确确认问题理解无误（通过 `question` 工具获取）
+✅ 所有潜在风险和影响已向用户说明（通过 `question` 工具确认）
+✅ 修复方案获得用户明确同意（通过 `question` 工具选择）
+✅ 相似逻辑和关联代码已同步处理（如适用）
+✅ 提供了完整的验证和测试建议
+
+## 示例工作流
+
+```
+用户: "策略计算结果不对，加价逻辑有问题"
+
+Agent:
+[阶段1 - 问题诊断]
+我需要确认几个细节：
+1. 具体是哪种类型的策略计算不对？（机票、动态加价、固定加价？）
+2. 能否提供一个具体的测试用例输入和错误输出？
+3. 预期的正确输出是什么？
+
+用户: "动态加价，百分比计算错误，应该是基准价×10%，但实际是×100%"
+
+Agent:
+[阶段2 - 根因分析]
+已定位到问题：
+- 位置: src/Domain.Service/Services/AgentService.cs:234
+- 原因: 百分比未除以100
+
+[阶段3 - 方案设计]
+⚠️ 发现以下需要确认的点：
+
+1. **关联代码**: 在 PolicyService.cs 中发现相似的百分比计算（3处），
+   是否也存在相同问题？
+   
+2. **单元测试**: UnitTestPolicy.cs:67 的断言值为100%，可能基于错误行为，
+   修复后需要更新测试
+
+3. **前端影响**: 如果历史数据按错误逻辑存储，前端展示需要迁移脚本吗？
+
+请确认是否需要一并处理这些关联问题？
+
+用户: "是的，PolicyService 也需要修复，测试用例也要改，历史数据没有存储"
+
+Agent:
+[阶段4 - 实施修复]
+好的，我将修复以下位置：
+1. AgentService.cs:234
+2. PolicyService.cs:156, 178, 201
+3. UnitTestPolicy.cs:67
+
+[执行代码修改...]
+
+[阶段5 - 验证建议]
+修复完成！建议验证：
+1. 运行单元测试: dotnet test
+2. 手动测试场景:
+   - 输入基准价1000，加价10%，期望结果1100
+   - 验证策略列表API返回正确百分比
+3. 回归测试: 检查其他类型策略未受影响
+```
+
+## 适用场景
+
+- ✅ 逻辑错误修复
+- ✅ 空指针异常修复
+- ✅ 数据计算错误
+- ✅ API行为异常
+- ✅ 性能问题修复
+- ✅ 边界条件处理
+
+## 相关技能
+
+- `refactor`: 重构优化（非bug修复）
+- `feature`: 新功能开发
+- `test`: 测试用例编写
+
+## 核心约束（必须遵守）
+1. **禁止开放式提问** - 所有需要用户输入的场景，必须提供选项列表
+2. 每次交互最多提出5个问题，避免信息过载
+3. 选项设计要穷举常见情况，并保留"其他"兜底选项