用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/liuzhengdongfortest/CodeStable --skill cs-brainstorm命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
基于 SOC 职业分类
正在显示 SKILL.md
| name | cs-brainstorm |
| description | 模糊想法分诊。触发：用户想先聊、brainstorm、方向摇摆；不处理 bug/重构。 |
brainstorm 是"讨论层"统一入口。
三件最重要的事：
共享路径和命名约定看
.codestable/reference/shared-conventions.md。需要 owner 在 interview / grill 中做路线、范围或下一步审批时，先读.codestable/reference/approval-conventions.md并把approval-report.md写到对应 brainstorm / feature / roadmap 目录。
| case | 规模 | 用户状态 | 产物 |
|---|---|---|---|
| case 1：已经够清楚 | 不限 | 一句话能说清做什么 / 为谁 / 怎么算成功 / 不做什么 | 确认后同轮进 cs-feat design |
| case 2：小需求 | 单 feature | 知道要解决什么问题，对解法 / 边界还摇摆 | 落 feature brainstorm，确认后同轮进 cs-feat design |
| case 3：大需求，拆解 ready | 多 feature | 心里已有大致模块划分，想直接做拆解和接口契约 | 不落盘，同轮进 cs-epic |
| case 4：大需求，想 grill | 多 feature | 还不想拆——想先 grill、发散、产生想法存着 | 落 open brainstorm，确认后同轮进 cs-epic |
判错 case 不是灾难——允许升降级。case 2 聊着发现范围越聊越大切 case 3/4，case 3 聊着发现需要先 grill 切 case 4，case 4 grill 完可以直接拆切 case 3，当场切换出口。
出口语义：case 1 / case 2 / case 4 是待确认出口；case 3 的 ready 拆解表述本身视为确认，是已确认出口。
每次都做：
.codestable/attention.md（缺失先 cs-onboard）；不要用 AGENTS.md/CLAUDE.md 等外部入口代替它；细则见 .codestable/reference/execution-conventions.md；Glob .codestable/ 发现 features / roadmap / brainstorms / compound / requirements 有哪些，命中和本次讨论相关的才深读：需要术语时读 requirements/CONTEXT.md、涉及已拍板决策时扫 requirements/adrs/、grep -r 关键词 compound/ 看相关坑、看相关 feature / roadmap / brainstorm；若本会话已加载过则复用，不重复 Glob+Read；Grep 用户描述里的关键词防术语冲突features/ 下有名字相近的 brainstorm？roadmap/ 下有相近子目录？brainstorms/ 下有相关创意记录？brainstorms/ 下有相关创意记录 → 读完汇报"之前 {日期} 存过一份脑暴记录，方向是 {…}，接着聊还是直接拆 roadmap？"cs-issue，重构走 cs-refactor不是填表——分类题问太多用户觉得在走流程。
用户只说一个模糊词 / 短句（"我想要一个权限系统"、"想聊聊通知"）：
一句话先对齐：你想解决的是 {AI 复述的问题} 对吧？这块你脑子里多大范围——是"加一个小能力"那种一个 feature 能装下的，还是"一整块新子系统得分几轮做"的规模？
用户带着方案来（"我想做 X，里面有 a/b/c"）：
复述一下看对不对——你想解决的问题是 {P}，打算做 X 包含 a/b/c。这里 a/b/c 合起来更像一个 feature 能搞定，还是三件互相有依赖的事要分几轮？
用户自己拆成多件 → 多 feature 规模，追问"想直接拆 roadmap 还是先 grill 存着？"→ case 3 或 case 4；a/b/c 是同一件事的不同面 → case 2；用户听完复述说"对就是这个想清楚了"→ case 1。
判 case 信号（用户说不清就 AI 自判）：
以下对话方法对 case 2 和 case 4 通用。case 2 最终要收敛到一个选定方向，case 4 可以更开放、不强制收敛。
1. 区分"用户说的"和"用户要的"——开口第一句往往是 TA 想到的方案不是真要解决的问题。听到"我想做 X"先别顺着聊方案，先问"X 是为了解决什么场景下的什么问题"。常见发现：真问题不是 X 能解决的，或有更小、更轻、完全不同方向的解法。一旦进 design 方向就焊死——在用户自己还没意识到之前完成这件事是 brainstorm 阶段最大价值。
2. 用户带着方案来时先评估再接受——不要直接进入"那我们聊聊 a 怎么做"。先做：
评估完发现方案确实合理 → "我觉得这个方向 OK 建议直接进 design"，别为凑流程硬发散——当场升级 case 1。
没有固定步骤。三个动作随时可回到上一步：
挖问题——按姿态 1 把"真正要解决的问题"问清楚，能用一句话复述、用户说"对就是这个"为止。这一步价值最高不要急着跳过
grill 档（按需启动，默认不开）
默认走轻问——一次复述对上就推进。下面任一信号出现切到 grill 档加深：
grill 档硬约束（防止没完没了）：
approval-report.md，不要只丢一个多选题发散——确认问题后再谈方案。提 2-3 个具体候选方向（用户带的方案算其中一个），每个 1-2 句描述 / 价值 / 代价。至少有一个反直觉候选（反转 / 去掉常见约束 / 跨领域类比）。所有候选呈现完再给推荐——先锚定再补别的会污染用户判断
收敛——选定方向后轻轻勾勒：核心行为？明显不做？最大未知？给 design 热身不是替 design 决定
讨论中冒出"这个方向能不能走得通要看 X 实际是不是 Y"——不要靠脑补辩论，停下来花 5-30 分钟搭个最小 demo 验一下比再聊三轮更省时。
默认不做——大多数 brainstorm 是在比较权衡，demo 帮不上忙。同时满足下面三条才主动提议：
cs-feat fastforward mode 直接做或拆成正式 feature提议格式："这块靠想不准，我做个最小 demo 验一下 {要验的事}，5-10 分钟，OK 吗？" 用户秒过 / 拒绝即可。
spike 落地约定：
.codestable/features/{feature}/ 下（和 brainstorm note 同目录），文件随便起名（spike.py / try-{topic}.ts）.codestable/brainstorms/{slug}/，跟 brainstorm.md 挨着{路径}）"，避免 design / roadmap 阶段再起疑重做case 1 / case 3 也能借这个动作（不强求落 brainstorm note），逻辑一样：事实存疑 + 改变方向 + 成本可控。
任何 case 下，讨论过程中只要拍板了符合 ADR 3 判据（难回退 + 不显然 + 真实权衡）的结构性决策——典型如选了某个库 / 模块拆分方式 / 跨模块通信模式 / 一个稳定的"我们不做 X"——提示用户：
这条决策听起来该写一条 ADR（难回退 + 选了具体方案）。要不要现在走
cs-domain落一条 ADR？
用户决定。不在 brainstorm 里直接写 ADR，由 cs-domain 处理。
信号：一句话能说出做什么 / 为谁 / 怎么算成功 / 不做什么；聊两句核心行为 / 成功标准都对上。
处理：
cs-feat design 阶段——brainstorm 对你没增量"退出：用户确认后在当前 run 加载 cs-feat，从零写 design；轻量落盘时同时传递 {路径}，不要求用户重新调用或重述
信号：知道要解决什么问题、大致做哪块，一个 feature 能装下，但对解法 / 边界还摇摆。
怎么聊：按上节"怎么聊"工具箱推进——挖问题 → 发散 → 收敛。收敛到选定方向后落盘。
升降级：
approval-report.md 解释"直接拆 roadmap vs 先 grill 存着"，再让 owner 选 → case 3 或 case 4落盘：收敛完成后写 .codestable/features/{feature}/{slug}-brainstorm.md。
目录约定：
只在用户确认进 design 那一刻落盘——对话期间不写文件。status 固定 confirmed，没有 draft。
文档模板见同目录 reference.md 的"feature brainstorm 模板"。frontmatter 字段口径跟 design / acceptance 共用一组，看 shared-conventions.md 第 1 节。
退出：如果只是轻确认，主动问"这块够清楚了可以进 design 吗？"；如果需要解释方案 / 代价 / 默认后果，先在 feature 目录写 approval-report.md 再让 owner 确认。确认后落盘，并在当前 run 加载 cs-feat design，传递 {路径} 与已敲定方向。如果愿景（用户故事 / 痛点 / 边界）已经聊透了，可先询问是否用 cs-req draft 落 requirement；这也是待确认出口，不能替用户改道
信号：多 feature 规模，用户心里已有大致模块划分，能说出拆法，想直接做拆解和接口契约。
处理：
cs-epic 会做拆解和依赖梳理，现在继续进入它的 planning"cs-epic planning 自己建目录和主文档退出：ready 拆解已经构成用户确认；附聊到的要点汇总，直接在当前 run 加载 cs-epic planning，不落盘
信号：多 feature 规模，但用户说不清模块边界、想先发散探索——"帮我问问清楚"、"先把想法理一理存着"、"方向还乱，聊开了再说"。
这是创意空间，不是设计文档。目标是产生可留存的想法、方向和洞察，供后续 epic planning 消费。
怎么聊：启动 grill 档（见上节"对话节奏 > grill 档"），同时自由发散——聊方案、聊类比、聊技术可能性、聊限制。对话比 case 2 更开放，不急着收敛。
升降级：
cs-epic，不新建 case 3 产物落盘：用户说"先这样"/"差不多了"/"存一下"，或 AI 判断 grill 已到 3-5 轮上限，主动说"这块我先帮你落到 brainstorms 里，之后 cs-epic 会读到"。
路径：.codestable/brainstorms/{slug}/
.codestable/brainstorms/{slug}/
└── brainstorm.md 创意记录
目录不存在就创建。slug 根据方向自拟英文小写连字符。
文档模板见同目录 reference.md 的"open brainstorm 模板"。
doc_type: brainstorm 区别于 case 2 的 feature-brainstorm和 epic 的衔接：cs-epic planning 阶段启动时会搜 .codestable/brainstorms/ 看有没有相关 brainstorm。如果有，内部 roadmap 主文档把 brainstorm 当输入材料读，不重复分诊直接拆。
退出：落盘后告诉用户"想法存到 {路径} 了"，并询问是否现在进入 epic planning；只有用户确认后才在当前 run 加载 cs-epic，同时传递该路径。如果 grill 中愿景已经比较清楚，可先询问是否用 cs-req draft 落 requirement；未经确认不自动改道
cs-epic