cs-brainstorm brainstorm 是"讨论层"统一入口。用户开口时 AI 不知道终点应落在哪——feature design / roadmap / 还是聊两句发现已经够清楚直接 design。本技能先用一两轮对话分诊，再把讨论交给合适下游。 三件最重要的事： brainstorm 是创意空间不是审计关卡 ——探索 / 质疑 / 改主意 / 聊着聊着发现真正想做的是另一件事都正常 任何话题都可以聊 ——用户想聊库 / Schema / 接口就聊；TA 提出来说明心里有谱，趁早讨论清楚 design 阶段更省力。不设话题黑名单 AI 是思考伙伴不是记录员 ——用户来这步是想被挑战、被启发，不是被一条条问题填表。如果只是把用户的话整理一遍写下来这步就白做了 共享路径和命名约定看 codestable/reference/shared-conventions.md 。 三种讨论、三个出口 情况 特征 出口 case 1：其实已经够清楚 一句话能说出"做什么 / 为谁 / 怎么算成功 / 不做什么"，不需要再 explore 直接 cs-feat-design （不落盘，告知用户后停） case 2：小需求，方向定但细节模糊 知道要解决什么问题、大致做哪块，对真问题 / 解法 / 边界还摇摆；一个 feature 能装下 codestable/features/{feature}/ 里讨论并落 {slug}-brainstorm.md ，之后进 cs-feat-design case 3：大需求，还只一个词 "我想要一个 X 系统 / 一套 Y 能力"，能预见拆出来是多个 feature，或最小闭环还说不清 cs-roadmap （不落盘，移交讨论） 判错 case 不是灾难—— 允许升降级 。case 2 聊着发现是 case 3（范围越聊越大）或 case 3 收窄成 case 2，当场告诉用户切换出口，不要硬撑。 开聊之前先做的检查 每次都做： 扫一眼仓库 ——读 AGENTS.md + architecture/ARCHITECTURE.md ；Glob features/ / roadmap/ ；Grep 用户描述里的关键词（防术语冲突）；搜 compound/ 看有没有相关坑（ --filter doc_type=learning ）。简短报告发现让用户知道你不是凭空在聊 是不是接续之前的工作 —— features/ 下有名字相近的 brainstorm？ roadmap/ 下有相近子目录？ 没有 → 当新讨论 有 brainstorm 内容是中断留下的 → 读完汇报"上次聊到 {…}，接着聊还是推翻？" 有同名 design.md → 告诉用户 design 已开，是不是走错入口 有同名 roadmap → 这块已在 roadmap 跟进，是不是要推进具体子 feature 确认这是新功能 brainstorm ——bug 走 cs-issue ，重构走 cs-refactor 开场判 case （下一节） 如果你已经能替用户写出 design 第 1 节需求摘要的初稿 ——告诉用户"我感觉你已经够清楚，直接进 feature-design 更省事"，当场判 case 1。揽下不属于自己的活是本阶段最大反模式 开场分诊：一两轮对话判 case 不是填表——分类题问太多用户觉得在走流程。 用户只说一个模糊词 / 短句 （"我想要一个权限系统"、"想聊聊通知"）： 一句话先对齐：你想解决的是 {AI 复述的问题} 对吧？这块你脑子里多大范围——是"加一个小能力"那种一个 feature 能装下的，还是"一整块新子系统得分几轮做"的规模？ 用户带着方案来 （"我想做 X，里面有 a/b/c"）： 复述一下看对不对——你想解决的问题是 {P}，打算做 X 包含 a/b/c。这里 a/b/c 合起来更像一个 feature 能搞定，还是三件互相有依赖的事要分几轮？ 用户自己拆成多件 → 八成 case 3；a/b/c 是同一件事的不同面 → 八成 case 2；用户听完复述说"对就是这个想清楚了"→ case 1。 判 case 信号 （用户说不清就 AI 自判）： 每一条目标是 同一件事的不同角度 → case 2 几条目标有 先后依赖 或 互相独立的子模块 → case 3 聊两句"不做什么 / 核心行为 / 成功标准"都对上 → case 1 三种 case 各自怎么处理 case 1：其实已经够清楚 告诉用户"这块你已经想清楚了：{AI 一句话复述}。建议直接 cs-feat-design ——brainstorm 对你没增量" 看聊过程有没有非琐碎技术决策 ——讨论了具体库选型 / Schema / 接口形态 / 跨模块约定，落一份精简 brainstorm（只填"已敲定的设计点"那节）让 design 直接读到不必重讨；纯方向确认没聊技术细节就裸退不落盘 停下来等用户触发 design case 2：小需求，在 feature 里继续讨论 按"怎么聊"一节推进，收敛后落 codestable/features/{feature}/{slug}-brainstorm.md 。 case 3：大需求，移交 roadmap 告诉用户"听起来是多个 feature 的集合，单 feature 装不下。 cs-roadmap 会做拆解和依赖梳理，我把讨论交给它" 把已聊的信息汇总让 roadmap 接手不用重来：真问题 / 大致范围 / 已提到的可能子模块（一句话各一）； 聊到的跨模块接口形态、共享协议、技术选型一并列出 ——这些是 roadmap 第 4 节"架构层详设"的种子 不落盘 —— roadmap new 自己建目录和主文档 告诉用户下一步触发 cs-roadmap 怎么聊（case 2 展开） 两条核心姿态 1. 区分"用户说的"和"用户要的" ——开口第一句往往是 TA 想到的方案不是真要解决的问题。听到"我想做 X"先别顺着聊方案，先问"X 是为了解决什么场景下的什么问题"。常见发现：真问题不是 X 能解决的，或有更小、更轻、完全不同方向的解法。一旦进 design 方向就焊死——在用户自己还没意识到之前完成这件事是 brainstorm 阶段最大价值。 2. 用户带着方案来时先评估再接受 ——不要直接进入"那我们聊聊 a 怎么做"。先做： 复述 + 反向追问问题 ——把方案翻成"你想解决的问题是不是 P" 评估并提替代 ——看到方案有明显问题（解错了 / 过度工程 / 有现成更轻路径 / 踩 learning 坑），直接说出来，提 1-2 个明显不同的替代方向。 不要为了显得配合就闭嘴 评估完发现方案确实合理 → "我觉得这个方向 OK 建议直接进 design"，别为凑流程硬发散——当场升级 case 1。 对话节奏 没有固定步骤。三个动作随时可回到上一步： 挖问题 ——按姿态 1 把"真正要解决的问题"问清楚，能用一句话复述、用户说"对就是这个"为止。 这一步价值最高不要急着跳过 挖问题的 grill 档 （按需启动，默认不开） 默认走轻问——一次复述对上就推进。下面任一信号出现切到 grill 档加深： 显式请求 ：用户说"多问几轮 / 帮我问清楚再开始 / grill 我" 隐式信号 ：连续两次复述被"差不多但不太对"驳回；同一概念用不同词反复互指（"权限 / 角色 / 租户"换着说指同一件事）；用户自己也说不清楚 只在 case 2 启动 ——case 1 已清楚再 grill 反人性，case 3 拆解归 roadmap grill 档的硬约束（防止变成 grill-me 那种没完没了）： 最多 3-5 轮重点问题，一轮没拿到新增信息就退到发散 每轮 一个问题 + 2-4 个有区别度的候选 让用户挑，不让 TA 自由作文 遇到"得写起来才知道"的问题：标成 design open question 直接跳过，不死磕 用户开始敷衍 / 说"先这样吧 / 差不多了" → 立刻退到收敛，别再追问 发散 ——确认问题后再谈方案。提 2-3 个具体候选方向（用户带的方案算其中一个），每个 1-2 句描述 / 价值 / 代价。 至少有一个反直觉候选 （反转 / 去掉常见约束 / 跨领域类比）。所有候选呈现完再给推荐——先锚定再补别的会污染用户判断 收敛 ——选定方向后轻轻勾勒：核心行为？明显不做？最大未知？给 design 热身不是替 design 决定 随时升降级 发现是大需求（子模块越聊越多有依赖）→ "这规模超出单 feature 建议切 roadmap"，按 case 3 移交 发现已经全清楚 → "我觉得已经够进 design"，按 case 1 停下 常见的坑 一次只问一个问题 ——抛三五个用户只回最容易答的 先给选项再提问 ——能用 2-4 个具体有区别度的选项让用户挑就别让 TA 自由作文 不要主动把话题拉回"用户感知层面" ——用户想聊库 / Schema / 接口 / 选型就跟着聊；AI 自己别主动开技术细节话题填时间，但用户开了的话题就认真陪聊。某问题的答案得看代码 → 按需读代码再带回对话 case 2 落盘 收敛完成后写 brainstorm note 到 codestable/features/{feature}/{slug}-brainstorm.md 。 feature 目录怎么建 日期前缀：从环境信息取今天日期 slug：根据方向自拟英文小写连字符，写进 note 时告诉用户。design 阶段改名只 rename slug 部分日期别动 目录不存在就创建；已存在回到上面"接续检查" brainstorm note 模板 只在用户确认进 design 那一刻落盘——对话期间不写文件。 status 固定 confirmed ，没有 draft。
doc_type : feature - brainstorm feature : YYYY - MM - DD - { slug } status : confirmed summary : 一句话讲选定方向 tags : [ ... ]
{功能名称} Brainstorm
Stage 0 | {YYYY-MM-DD} | 下一步：design
想做什么、为什么
考虑过的方向
方向 A：{名}
描述 / 价值 / 代价
结论：选定 / 否决（原因）
方向 B / C ...
已敲定的设计点 {聊过程已达成共识的具体设计——库选型 / Schema / 接口形态 / 技术约束} {每条标：已确认 / 倾向 / 待验证。design 直接落，不重复讨论}
选定方向与遗留问题 {选定方向 2-3 句重述 + 粗粒度轮廓（核心行为 / 明显不做 / 最大未知）+ 遗留给 design 的问题} frontmatter 字段口径跟 design / acceptance 共用一组，看 shared-conventions.md 第 1 节。 退出 退出时 告诉用户下一步触发哪个技能、读哪份文件 ： case 1 裸退 ：告诉用户"直接触发 cs-feat-design 从零写 design"，不落盘 case 1 带轻量落盘 ：有非琐碎技术决策时落 brainstorm（只填"已敲定的设计点"），告诉用户"下一步 cs-feat-design 会读到 {路径} 不必重述" case 2 ：主动问"这块够清楚了可以进 design 吗？"，确认后落盘，告诉用户"下一步 cs-feat-design 会读到 {路径} " case 3 ：告诉用户"移交给 cs-roadmap "，附聊到的要点汇总（含技术讨论部分），不落盘 别自己顺手开始写 design 或 roadmap ——阶段间的人工 checkpoint 是 CodeStable 整套流程的硬约束。 硬性边界 不跳过分诊 ——任何长度的讨论开始前都要先判 case 不替用户决定规模 ——case 2/3 边界模糊就问用户"你脑子里这块是一个 feature 能装下的规模吗" 不落盘非 case 2 产物 ——case 1/3 不写文件 不处理 bug / 重构 不在 case 1/3 启动 grill 档 ——case 1 已清楚硬 grill 反人性，case 3 拆解是 roadmap 的活 常见错误 跳过分诊默认所有讨论按 case 2 推进——大需求被硬塞进一个 feature 分诊问得像问卷——一两轮该有方向；问到第三轮还在对齐规模说明方法错了 case 1 硬凑 brainstorm note——用户已清楚还写一份模板，后人误以为这里发生过有价值讨论 case 3 自己做拆解——越俎代庖，那是 roadmap 的产物 升降级信号不理——范围扩大还继续 case 2，最后落一份塞不下所有子模块的 note 一次只给一个方案让用户评价——用户被锚定提不出别的方向 复述用户方案就落盘——记录员心态，AI 没提供思考伙伴的价值