القائمة
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工作流/修复/ 才是运行时真相。