drafting-specs

# 起草规格 当请求还新、还模糊、还没变成书面已批准 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 ## 流程 1. 先确认用户已明确给出 spec 目标; 没给就停下反问 "请描述本次 spec 目标: 要解决什么 / 交付什么? 不要让我猜。" 拿到答复再继续 2. 看项目上下文、约束、现有文档、文件布局 3. 和用户澄清到足够写出具体 spec 4. 把 spec 落盘 5. 派 worker 做对抗式 review 6. 要求 worker 重点找： - 行为歧义 - 隐藏依赖 - 不可测 acceptance criteria（仅内部行为） - 缺 failure handling（仅内部路径） - scope 大到无法 phase 化 - 单独列出 `external_dependency_risks`：第三方 API / 外部服务的错误处理与测试缺口。此类**不**作为 critical，不触发 revise 7. 如果 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. 8. 如果 worker 通过，或用户 override 剩余问题： - **在请求用户批准前，必须单独朗读 `external_dependency_risks` 清单**（如有），让用户知情 - 把当前 spec 交给用户审批 9. 明确批准前，停在这里。批准后才进 `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