| name | spec |
| description | Use when the user wants to start or continue a cc-leader workflow, write a spec, or says '/cc-leader-spec'. Guides spec drafting, resume, and adversarial review. |
启动 Spec Workflow
这是 cc-leader workflow 的用户入口。用户要新开 workflow、写 spec、或直接说 /cc-leader-spec 时，用这个 skill。
权威边界: 本 skill 管 spec 阶段 gate + cc-leader CLI 调用。spec 内容规则 (角色 / 对抗审重点 / 反模式) 的真源是 drafting-specs skill, 此处不复述。spec 章节真源是 docs/templates/spec-template.md。
核心规则
- 这是 spec 阶段入口，不直接进入 planning 或 execution
- spec 目标必须由用户明确提供, 严禁猜测 / 脑补 / 用历史会话 / 用 git 状态推断. 用户没说目标就停下来问, 拿到目标再继续
- 只用
cc-leader CLI 操作 workflow state，不要直接编辑 .cc-leader/session.json 或其他 session state 文件
- spec 按
docs/templates/spec-template.md 的结构写
- 一次最多问一个阻塞问题；非阻塞假设写进 spec
流程
- 建议用户切换模型: "建议切换到 Opus 4.8 (1M context) 模型以获得最佳 spec 质量。可用 /model 切换 (cc 无法自切, 需用户手动)。"
- 强制 spec 目标 gate (先于一切动作):
- 检查用户本次请求是否含明确 spec 目标 (要做什么 / 解决什么问题 / 交付什么)
- 仅给 slug / "新开 workflow" / "/cc-leader-spec" 等无目标信息时, 停止, 反问用户:
- "请描述本次 spec 目标: 要解决什么问题 / 交付什么? 不要让我猜。"
- 拿到用户明确答复后再继续
- 绝不用历史会话 / memsearch / git 状态 / 目录内容 / 上一次 spec 反推目标
- 强制 worktree gate (避免 state 文件覆盖):
- 执行
pwd 确认当前 CWD
- 若 CWD 不在
<project-root>/worktrees/<name> 内 (即仍在主工作树或别处):
- 询问用户 worktree 名 (新任务簇名 / 复用现有)
- 新建:
git worktree add worktrees/<name> -b cc-leader/<name>
- 进入:
EnterWorktree path=worktrees/<name> (后续所有 cc-leader CLI 都在 worktree CWD 跑)
- 若已在某 worktree 内: 直接继续, 该 worktree 的
.cc-leader/session.json 是本 spec 的独立 state
- 关键:
cc-leader state 文件按 CWD 存; state 已存在时 init 不加 --force 会被拒, 但若在主仓加 --force 重开, 会覆盖该 CWD 的既有 workflow state
- 检测已有 workflow: 执行
cc-leader state:get
- 如果已有 workflow 且
spec_approved == true:
- 提示用户: "已有已批准的 workflow <workflow_id>, spec 在 <spec_path>。用 /cc-leader-run 继续执行。"
- 停止, 不重复 init
- 如果已有 workflow 且
spec_approved == false 且 spec_path 非空:
- 提示用户: "发现未完成的 workflow <workflow_id>, spec 在 <spec_path>。"
- 问用户: "继续编辑这个 spec, 还是放弃重开?"
- 用户选继续 → 跳到步骤 5, 读已有 spec 继续改
- 用户选重开 → 执行
cc-leader init --slug <slug> --force, 走正常新建流程
- 如果没有 workflow (state:get 报错或 workflow_id 为空):
- 确认或和用户约定 workflow slug, 执行
cc-leader init --slug <slug>
- 执行
cc-leader state:get, 读取 workflow_id
- 和用户一起按
docs/templates/spec-template.md 起草 spec。
- 章节真源 = 该模板, 按模板全部章节写, 不在本文件复述清单 (避免 drift)
外部依赖风险 / 开放问题 不能留空, 没有写 none
- 将 spec 落盘到
docs/specs/<workflow-id>.md
- 执行
cc-leader state:set --set spec_path=docs/specs/<workflow-id>.md
- 派 worker 做对抗式 review：
cc-leader dispatch --job specAdversarialReview
- 如果 review 结果是
pass：
- 向用户总结 review 结论
- 单独汇报外部依赖风险: 从 review 文档读取
external_dependency_risks 段
- 若非
none, 逐条朗读给用户, 格式 <依赖>: <风险> — 建议: <缓解>
- 明确告知用户: "以下风险不阻塞批准, 但建议知情; 最终报告会再次汇总。"
- 若为
none, 简短告知 "无外部依赖风险记录"
- 询问用户是否批准 spec
- 用户批准后执行
cc-leader state:set --set spec_approved=true --set spec_review_passed=true
- 明确提示用户：
spec 已批准。用 /cc-leader-run 启动执行。
- 如果 review 结果是
revise：
- 总结关键问题、隐含假设、建议修改
- 每轮都先执行
cc-leader state:get, 读取 spec_review_revise_count (CLI 已自动维护)
- 若
spec_review_revise_count < 2:
- 和用户一起改 spec
- 重新执行
cc-leader dispatch --job specAdversarialReview
- 若
spec_review_revise_count >= 2:
- 强制停止自动循环. 不要再 dispatch, 不要继续问"要不要再审"
- CLI gate 兜底: 此时若直接
dispatch --job specAdversarialReview 会被拒, 错误信息会指引三选一
- 向用户展示累积问题清单 (本轮 + 历史 review 聚合), 让用户三选一:
- 接受当前 spec, 走 override 流程 (跳步骤 11)
- 放弃本次 workflow
- 明确要求再审一轮 — 用户必须主动说"再审一轮"或同义指令, Claude 才能执行
cc-leader dispatch --job specAdversarialReview --allow-after-revise-cap 跑一次
- 旁路后若仍 revise, 计数器继续 + 1, gate 再次触发, 重复三选一流程; 严禁自动重试
- 绝不自动
state:set --set spec_review_revise_count=0, 也绝不自动加 --allow-after-revise-cap; 两者必须由用户主动触发
- 如果用户明确要求 override：
- 记录 override 原因、范围、被跳过的 review 问题
- 把 override 写进 spec 的
Override 记录
- 继续 review / approval 流程
审查要求
- review 必须是对抗式，不是走过场
- 重点检查（critical 级）: 行为歧义、隐藏依赖、不可测成功标准（内部）、内部路径失败处理缺失、scope 大到无法 phase 化
- 外部依赖 (第三方 API / 外部服务) 的错误处理和测试覆盖单独归入
external_dependency_risks, 不进 critical, 不触发 revise
开放问题 不能留空；没有就写 none外部依赖风险 不能留空；没有就写 none
退出条件
docs/specs/<workflow-id>.md 已写好spec_path 已通过 cc-leader state:set 写回 state- spec review 已通过，或 override 已记录
- 用户已明确批准
