菜单
CX 工作流 — Bug 修复。当用户提到"修 bug"、"fix"、"报错"、"debug"、 "修复"时触发。默认走快速修复路径，复杂问题再升级为更深入的调查。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
CX 工作流 — 配置管理。查看或修改项目级 `开发文档/CX工作流/配置.json` 中公开的少量字段。仅在用户明确调用 `/cx:cx-config` 时执行。
CX 工作流 — 项目初始化。每个项目都单独确认 developer_id、GitHub 同步策略、 agent teams、code review、worktree isolation、auto memory，并建立项目级 `开发文档/CX工作流 + .cx` 运行时真相目录。仅在用户明确调用 `/cx:cx-init` 时执行。
CX 工作流 — 需求收集与规模评估。当用户提到"新功能"、"需求"、"PRD"、 "我想做一个"、"帮我规划"、"收集需求"、"功能规划"时触发。 多轮对话收集需求，自动评估规模，保存到本地 开发文档/CX工作流/功能/{feature_title}/需求.md，并自动判断是否需要 Design。
CX 工作流 — 项目蓝图探讨。当用户提到"蓝图"、"整体规划"、"项目范围"、 "scope"、"项目探讨"、"功能方案"时触发。多轮对话探讨项目或功能方案， 将结果保存到本地 `开发文档/CX工作流/功能/{功能标题}/范围.md`， 可选同步到 GitHub Issue（基于 config.github_sync 模式）。
Codex 侧 CX 架构决策记录。沉淀设计取舍，不改变 lease 与 worktree 持有关系。
Codex 侧 CX 配置管理。查看或修改项目级 开发文档/CX工作流/配置.json，并保持双运行器配置清晰。
| name | cx-fix |
| disable-model-invocation | false |
| description | CX 工作流 — Bug 修复。当用户提到"修 bug"、"fix"、"报错"、"debug"、 "修复"时触发。默认走快速修复路径，复杂问题再升级为更深入的调查。 |
先快修，只有问题明显复杂时才升级成更重的调查。
所有文件读写必须使用绝对路径。 禁止使用 ../ 相对路径。先用 git rev-parse --show-toplevel 获取绝对路径。
cx-fix 对 worktree 的要求比其他 skill 宽松：
--inline 模式）执行前检测：
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 只承担同步记录，不是修复主控。
本地 开发文档/CX工作流/修复/ 才是运行时真相。