| name | cx-fix |
| disable-model-invocation | false |
| description | CX 工作流 — Bug 修复。当用户提到"修 bug"、"fix"、"报错"、"debug"、 "修复"时触发。默认走快速修复路径，复杂问题再升级为更深入的调查。
|
cx-fix: 轻量修复与复杂升级
先快修，只有问题明显复杂时才升级成更重的调查。
强制规则
所有文件读写必须使用绝对路径。 禁止使用 ../ 相对路径。先用 git rev-parse --show-toplevel 获取绝对路径。
Worktree 检测
cx-fix 对 worktree 的要求比其他 skill 宽松：
- 小修复（bug fix、hotfix）：允许在当前分支直接修复（
--inline 模式）
- 大修复（涉及多文件重构）：建议创建 worktree 隔离
执行前检测：
check_output=$(bash ${CLAUDE_PLUGIN_ROOT}/scripts/cx-worktree.sh check \
--inline \
--project-root "$(git rev-parse --show-toplevel)" 2>&1) || true
默认 inline 模式，不强制 worktree。
先阅读：
${CLAUDE_PLUGIN_ROOT}/core/workflow/README.md${CLAUDE_PLUGIN_ROOT}/core/workflow/protocols/fix.md
使用方法
/cx:cx-fix {问题描述}
/cx:cx-fix
默认路径
- 调查复现
- 定位根因
- 最小修复
- 运行最相关验证
- 记录修复结论
- 提交代码
这是 Claude Code 侧的 cc adapter 修复入口；如果当前问题归属的 feature 已由 codex 持有，先提示 handoff，再决定是否继续。
优先调用共享 runner：
bash ${CLAUDE_PLUGIN_ROOT}/scripts/cx-workflow-fix.sh \
--title "<问题标题>" \
--runner cc \
--session-id <session-id>
升级条件
只有这些情况才把修复升级为复杂模式：
- 根因不明确，需要多假设并行调查
- 涉及多个模块或高风险兼容性
- 修复失败后出现连锁回归
- 需要结构化记录阻塞原因
产物与路径
修复记录保存到：
开发文档/CX工作流/修复/{问题标题}/修复记录.md
如果修复过程被阻塞，也应在修复记录里写明：
- 已尝试了什么
- 当前卡在哪里
- 是否需要用户决策或外部信息
提交规范
fix 路径提交使用：
fix(scope): description [cx-fix:<fix-slug>]
示例：
fix(liuyao): repair divine transaction path [cx-fix:liuyao-divine-500]
与 GitHub 的关系
GitHub 只承担同步记录，不是修复主控。
本地 开发文档/CX工作流/修复/ 才是运行时真相。
