| name | drafting-specs |
| description | 当 cc 需要和用户一起产出已批准 spec,并在进入 planning 前做 worker 对抗式 review 时使用。 |
起草规格
当请求还新、还模糊、还没变成书面已批准 spec 时,用这个 phase。
前置 (继承自 using-cc-leader, 若本 skill 被直接激活务必自查): 必须在 worktrees/<name> worktree 内 (state 按 CWD 存); 读 artifact 守 token 节流 — head/grep 抽段, 不全文 Read。
角色
cc: 和用户交互,定 scope,写 spec,决定是否继续 review loop
worker: 对 spec 做对抗式 review,专门挑错
规则
- 用户没批准 spec 前,不进 planning
- spec 目标必须由用户明确提供, 严禁猜测 / 脑补 / 用历史会话 / 用 git 状态 / 用既有文件反推. 用户没说目标就停下问, 拿到目标再继续
- 一次最多问一个阻塞性问题
- 提方案前先看 repo
- worker review 必须是对抗式,不是走过场
- 用户如果要停 review loop,记录 override
流程
- 先确认用户已明确给出 spec 目标; 没给就停下反问 "请描述本次 spec 目标: 要解决什么 / 交付什么? 不要让我猜。" 拿到答复再继续
- 看项目上下文、约束、现有文档、文件布局
- 和用户澄清到足够写出具体 spec
- 把 spec 落盘
- 派 worker 做对抗式 review
- 要求 worker 重点找:
- 行为歧义
- 隐藏依赖
- 不可测 acceptance criteria(仅内部行为)
- 缺 failure handling(仅内部路径)
- scope 大到无法 phase 化
- 单独列出
external_dependency_risks:第三方 API / 外部服务的错误处理与测试缺口。此类不作为 critical,不触发 revise
- 如果 worker 找到关键问题(critical):
- 向用户总结问题
- 和用户一起改 spec
- 再跑一次对抗式 review
- 2 轮 revise 上限: 每轮 dispatch 前先
cc-leader state:get 看 spec_review_revise_count. >= 2 时硬停, 让用户三选一 (override / 放弃 / 明确要求再审一轮并用 --allow-after-revise-cap). 详细规则见 spec skill (skills/spec/SKILL.md) 的 revise 上限段. 严禁自动重置计数器或自动加旁路 flag.
- 如果 worker 通过,或用户 override 剩余问题:
- 在请求用户批准前,必须单独朗读
external_dependency_risks 清单(如有),让用户知情
- 把当前 spec 交给用户审批
- 明确批准前,停在这里。批准后才进
writing-phase-plans
规格必含部分
章节真源 = docs/templates/spec-template.md, 按模板全部章节写, 不在本文件维护清单 (避免与模板 / spec skill 三处 drift)。
模板已覆盖, 但本 phase 强制非空 (没有就写 none):
external_dependency_risks(第三方依赖相关风险)
open questions
Worker 审查输出
至少要有:
- verdict:
pass 或 revise
- critical findings
- advisory findings
- external_dependency_risks
- suggested changes
- assumptions the worker had to make
退出条件
只有全部满足才离开:
- 已有书面 spec
- 对抗式 review 已通过,或已明确 override
- 用户已明确批准 spec
反模式
- 没书面 spec 就谈实现
- 把 worker review 当 rubber stamp
- 带着未解歧义进 planning