fix

Prompt file imported from doccker/cc-use-exp (.claude/commands/fix.md). Fill in {{arguments}} before use. Copyright stays with the author.

流程主权声明：本命令是用户显式调用的修复/调试工作流，已内置「快速修复」(模式 1) 和「debug 系统化调试」(模式 2) 两套独立流程。 禁止在本流程执行期间调用 superpowers:systematic-debugging、superpowers:brainstorming、superpowers:writing-plans 或任何会接管修复/调试流程的外部 skill；本命令自己就是调试流程，无需再嵌套一层。 业务领域类 skill（如 redis-safety、api-contract-safety、payment-callback-safety、time-zone-safety 等触发条件匹配的安全/规范类技能）正常按需加载，仅作防御性参考，不接管流程。 本声明依据 superpowers 自身的优先级规则：用户显式指令 > superpowers skills。

根据参数选择模式：

• /fix [问题描述] → 快速修复（定位 → 修复 → 验证）
• /fix debug [问题描述] → 系统化调试（复现 → 假设 → 验证 → 报告，不直接改代码）

参数值：「{{arguments}}」

模式 1：快速修复（默认）

快速修复问题，一条龙服务。

⚠️ 来自 code-review 的变更范围约束

当输入以 [code-review] 开头时，必须遵循以下强制规则：

流程

1. 定位问题

根据描述搜索相关代码，找到问题根源。

2. 修复

直接修复，不需要确认（除非有多个方案）。

3. 验证

如果有相关测试，运行测试验证。

4. 输出

## 问题
[问题描述]

## 原因
[根因分析]

## 修复
[修改的文件和内容]

## 验证
✅ 测试通过 / ⚠️ 需手动验证

模式 2：debug（系统化调试）

系统化调试问题，遵循科学调试方法。本模式仅分析，不修改代码。

流程

1. 复现问题

• 确定最小复现步骤
• 记录错误信息和上下文
• 确认问题可稳定复现

2. 收集线索

• 搜索相关代码
• 查看最近的变更（git diff/log）
• 检查日志和错误信息

3. 提出假设

列出 2-3 个可能的原因，按可能性排序：

假设 1: [最可能的原因]
假设 2: [次可能的原因]
假设 3: [其他可能]

4. 验证假设

• 一次只改一个变量
• 记录每次验证的结果
• 直到定位根因

5. 输出报告

## 问题描述
[问题的具体表现]

## 根因分析
[问题的根本原因]

## 调试过程
1. [假设 1] → [验证结果]
2. [假设 2] → [验证结果]

## 建议修复
[修复方案，但不直接修改代码]

## 预防措施
[如何避免类似问题]

注意事项

• 本模式仅用于调试分析，不修改代码
• 如需修复，请使用 /fix [问题描述]
• 对于复杂问题，可能需要多轮调试