Menu
The review-first prompt is selected by default. You can switch to a direct command or download a local copy.
Read SKILL.md and any companion files shown by SkillsMP before deciding whether to install.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
A direct command skips the review prompt. Inspect the source before running it.
npx skills add https://github.com/liuzhengdongfortest/CodeStable --skill cs-brainstormThe command stays on one line. Scroll horizontally to inspect it before copying.
Prefer a local copy? Download the files currently available to SkillsMP.
CodeStable skill 工程化闭环入口。触发：写/改一个 cs skill、评测 skill 效果、跨 model/agent 量化、优化 skill 提示词、把收敛结论固化回 skill。内部推进 author、eval、optimize、release。
CodeStable 使用反馈闭环。触发：用户反馈 cs skill 跑偏、工具失败、规则没讲清、agent 被用户纠正；显式调用后采集本机证据并准备可确认的公开 issue。
CodeStable 接入。触发：初始化/迁移/搭骨架，自动判断空仓库或已有文档。
Based on SOC occupation classification
Showing 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