| name | cx-plan |
| description | CX 工作流 — 任务规划与契约下沉。当用户提到"规划任务"、"制定计划"、 "plan"、"拆分任务"时触发。读取设计文档（小功能则读取 PRD）， 生成任务分解，创建子任务文件并将契约下沉到任务中。 产物保存到本地 开发文档/CX工作流/功能/{feature_title}/任务/。
|
cx-plan: 任务规划与契约下沉
把需求或设计真正变成能执行的任务图，而不是再写一层描述文档。
先阅读：
${CLAUDE_PLUGIN_ROOT}/core/workflow/README.md${CLAUDE_PLUGIN_ROOT}/core/workflow/protocols/plan.md
强制规则
所有文件读写必须使用绝对路径。 禁止使用 ../ 相对路径。先用 git rev-parse --show-toplevel 获取绝对路径。
Worktree 检测（强制）
禁止在主分支（main/master）上执行规划阶段。必须在 feature worktree 中。
执行前检测：
check_output=$(bash ${CLAUDE_PLUGIN_ROOT}/scripts/cx-worktree.sh check \
--feature "{feature-slug}" \
--project-root "$(git rev-parse --show-toplevel)" 2>&1) || true
如果返回 on_main=true：
- 提示用户先运行
/cx:cx-prd 创建 worktree，或手动进入已有 worktree
- 用
AskUserQuestion 列出可用 worktree 供选择
- 不要继续执行规划阶段
使用方法
/cx:cx-plan {功能名}
/cx:cx-plan
规划原则
- 默认轻量，普通功能直接拆任务
- 仅当 PRD 明显引入新技术时，才进入技术识别和 skill 准备支线
- 任务目录使用中文显示名，状态关联始终用稳定
slug
- Claude Code 侧规划属于 runner
cc 的 adapter 行为；共享 core 被 codex 持有时先建议 handoff
- 允许在用户明确确认“进入规划阶段”后，由工作流自动衔接到本 skill
核心步骤
Step 0: 定位 feature 目录
PROJECT_ROOT=$(git rev-parse --show-toplevel)
CX_DOCS_DIR="$PROJECT_ROOT/开发文档/CX工作流"
FEATURE_TITLE="{功能标题}"
FEATURE_SLUG="{feature-slug}"
FEATURE_DIR="$CX_DIR/功能/$FEATURE_TITLE"
TASK_DIR="$FEATURE_DIR/任务"
mkdir -p "$TASK_DIR"
Step 1: 选择规划输入
- 小功能：直接读取
需求.md
- 中大功能：读取
设计.md，必要时参考 需求.md
不再要求手工传 --skip-design 才能走轻量路径。
Step 2: 新技术判断
仅当 PRD 明显引入新技术时，额外执行：
- 技术栈识别
- 现有项目兼容性检查
- 必要 skill 或外部文档准备
普通功能跳过这条支线，直接进入任务拆分。
Step 3: 生成共享契约（跨层任务时 MUST）
当任务图涉及 2 个及以上层级（前端+后端、后端+数据库等）时，
必须（MUST）先生成共享契约文件，再拆任务。
契约文件位置：
开发文档/CX工作流/功能/{功能标题}/契约.md
契约至少包含：
## API 契约
| 接口 | 方法 | 路径 | 请求体 | 响应体 |
|------|------|------|--------|--------|
| 分类树 | GET | /api/case-volume-category/tree | - | CategoryTree[] |
| 案例列表 | GET | /api/historical-case/list | QueryParams | PageResult |
## 数据模型契约
| 字段 | 类型 | 说明 |
|------|------|------|
| id | number | 主键 |
## 状态/枚举契约
| 枚举名 | 值 | 说明 |
|--------|-----|------|
契约来源优先级：
- 后端已有的路由/Controller → 读代码提取真实路径
- Design 文档中定义的接口 → 直接引用
- 都没有 → 在契约文件中新定义，前后端任务共同引用
禁止前后端任务各自猜测 API 路径。
Step 4: 生成任务 DAG
每个任务至少包含：
numbertitlephasedepends_onparallel- 验收标准
- 引用的契约条目（哪些 API、哪些数据模型）
跨层依赖规则：
- 前端任务依赖后端任务时，
depends_on 必须显式声明
- 前端任务文档中必须写明引用的 API 路径（来自契约文件），不能自行定义
- 后端任务完成后，如果实际路径与契约不一致，必须先更新契约再继续
Step 5: 写入任务文档
任务文件统一为：
开发文档/CX工作流/功能/{功能标题}/任务/任务-1.md
开发文档/CX工作流/功能/{功能标题}/任务/任务-2.md
任务文档里要同时保留：
- 可见中文标题
- 稳定
slug
- 目标文件范围
- 引用的契约条目（精确到路径和字段）
- 验收标准
Step 5: 更新 feature 级状态
feature 级 状态.json 至少包含：
{
"feature": "功能标题",
"slug": "feature-slug",
"status": "planned",
"tasks": [
{
"number": 1,
"title": "建立接口骨架",
"status": "pending"
}
],
"worktree": {
"preferred_branch": "codex/vector-memory",
"preferred_worktree_path": "/worktrees/vector-memory",
"binding_status": "recommended"
},
"docs": {
"prd": "需求.md",
"design": "设计.md",
Step 6: 输出执行建议
规划完成后默认建议：
下一步：/cx:cx-exec
执行开始时会询问：创建独立工作区 or 当前分支直接开始
如果任务图中存在清晰并行组，再在状态中标注 parallel_group，供 /cx:cx-exec --all 使用。
