brainstormlisted

# Spec 构思 把开放想法收敛成用户批准过的 **Spec**，再交给 `plan`。不写生产代码，不写 Executable Plan。 Canonical Spec path: `docs/specs/YYYY-MM-DD--<topic>.md`。不要因为仓库存在 `docs/prd/`、root `plan.md`、issue、design docs 或其他任务系统就改写默认位置。只有当前用户明确指定路径，或 `AGENTS.md` 明确声明 canonical Spec surface 时，才允许 override，并在输出中说明 override reason。不要默认写三文件；recovery surface 只在项目要求时收短摘要。 ## 语言策略 - 用户可见文本跟随用户语言；中文用户场景下，澄清问题、Coverage 说明、Spec 标题和模板提示默认使用中文。 - 协议稳定优先：协议 token 如 `BRAINSTORM CLARIFICATION IN PROGRESS`、`BRAINSTORM SPEC READY`、`Spec`、`Gate`、路径、skill 名和状态枚举可保留英文，必要时用中文标签补充解释。 - 不把“使用中文”硬编码为全局规则；英文用户或其他语言用户按其主要输入语言输出。 - 输出契约中的 `<... label in user's language>` 是占位说明，实际回复时必须替换成用户语言标签，不要原样输出。 ## 目的 - 防止模糊想法过早进入计划或实现。 - 在选择方案前先把验证策略说清楚。 - 通过独立 Spec 留下 goals、non-goals、方案取舍、成功标准和 plan handoff。 ## 路由快照 - **Use when**: 目标、边界、取舍、成功标准或验证路径不清，且需要先收敛 Spec。 - **Do not use when**: Spec 已批准、任务是单点小改、或用户只要事实回答。 - **Route to**: Spec 批准后转 `plan`；若发现项目工作面缺口，转 `harness-builder`。 ## 何时使用 ### 触发信号 - 意图仍开放，方案需要取舍。 - 成功标准、约束、non-goals 或验证路径不清。 - 用户说先 brainstorm、先讨论、先落 Spec、需求还没定、不要直接写代码。 ### 不要使用 - 已有完整 Spec 且验证清楚：转 `plan`。 - 任务是单点小补丁：直接做并按需记录 evidence。 - 用户只要事实回答、翻译或格式整理。 ### 路由规则 | 状态 | 下一步 | | --- | --- | | 需求、边界或验证策略未定 | **本 skill** | | Spec 已写但未批准 | 继续本 skill | | Spec 已批准 | `plan` | | Spec 已批准且工作面/recovery surface 缺失 | `harness-builder` | | 单点小改 | 退出 brainstorm | ## 先读取这些输入 1. `references/clarification-loop.md` 和 `references/clarification-coverage.md`。 2. 既有 Spec、PRD、issue、plan、README、`AGENTS.md`、相关代码与测试。 3. selected recovery surf