diff --git a/asset/CodeStabvle.png b/asset/CodeStabvle.png
index d78324e..d7f0739 100644
Binary files a/asset/CodeStabvle.png and b/asset/CodeStabvle.png differ
diff --git a/asset/PromotionalImage.png b/asset/PromotionalImage.png
index 8016caa..0da6b09 100644
Binary files a/asset/PromotionalImage.png and b/asset/PromotionalImage.png differ
diff --git a/cs-brainstorm/SKILL.md b/cs-brainstorm/SKILL.md
index f467eb8..d15e085 100644
--- a/cs-brainstorm/SKILL.md
+++ b/cs-brainstorm/SKILL.md
@@ -9,7 +9,8 @@ brainstorm 是"讨论层"的统一入口。用户开口时，AI 并不知道这
 
 两件最重要的事：
 
-- **brainstorm 是创意空间，不是审计关卡**。在这里探索、质疑、改变主意、聊着聊着发现真正想做的是另一件事——都正常。约束和落地细节留给下游技能。
+- **brainstorm 是创意空间，不是审计关卡**。在这里探索、质疑、改变主意、聊着聊着发现真正想做的是另一件事——都正常。
+- **任何话题都可以聊**。用户想聊用什么库、表怎么设计、接口怎么定，那就聊——TA 既然提出来，说明心里已经有谱，趁早讨论清楚，design 阶段反而更省力。brainstorm 不设话题黑名单，不要把用户的具体问题硬推到 design。
 - **AI 是思考伙伴，不是记录员**。用户来这一步是想被挑战、被启发，不是来被一条条问题填表的。如果你只是把用户的话整理一遍写下来，那这一步就白做了。
 
 > 共享路径和命名约定看 `codestable/reference/shared-conventions.md`。
@@ -48,7 +49,7 @@ brainstorm 是"讨论层"的统一入口。用户开口时，AI 并不知道这
 
 ## 开场分诊：一两轮对话判 case
 
-分诊的目的是尽快把这次讨论交给对的下游。**不是填表**——问太多分类题会让用户觉得在走官僚流程。
+分诊的目的是尽快把这次讨论交给对的下游。**不是填表**——问太多分类题会让用户觉得在走流程。
 
 ### 分诊的问法
 
@@ -83,10 +84,10 @@ brainstorm 是"讨论层"的统一入口。用户开口时，AI 并不知道这
 动作：
 
 1. 告诉用户"这块你已经想清楚了：{AI 一句话复述做什么 / 为谁 / 怎么算成功 / 明确不做}。建议直接走 `cs-feat-design`——brainstorm 对你没增量价值"
-2. 本技能**不落盘**——没产出 `{slug}-brainstorm.md`，也不建 feature 目录（design 阶段会建）
+2. **看聊过程里有没有非琐碎的技术决策**——如果用户在判 case 1 之前其实已经讨论了具体的库选型 / Schema / 接口形态 / 跨模块约定，落一份精简 `{slug}-brainstorm.md`（只填"已敲定的设计点"那一节即可），让 design 阶段直接读到、不必重新讨论；如果纯方向确认、没聊技术细节，则裸退不落盘
 3. 停下来，等用户触发 design
 
-为什么这样处理？brainstorm 的价值在"把模糊聊清楚"，模糊没了这步就是负担。硬凑一份 brainstorm note 会让后人以为这里真发生过有价值的讨论。
+为什么这样处理？brainstorm 的价值在"把模糊聊清楚"——模糊没了就裸退；但已经聊清楚的具体设计点是真产出，不能因为整体定性是 case 1 就丢掉。
 
 ### case 2：小需求，在 feature 里继续讨论
 
@@ -97,7 +98,9 @@ brainstorm 是"讨论层"的统一入口。用户开口时，AI 并不知道这
 动作：
 
 1. 告诉用户"这块听起来是多个 feature 的集合，单个 feature 装不下。brainstorm 对这种规模的讨论不是好入口——`cs-roadmap` 会做拆解和依赖梳理，我现在把讨论交给它比较合适"
-2. 把已经聊到的信息做一句话汇总（真问题 / 大致范围 / 已经提到的可能子模块），方便 roadmap 技能接手不用重来
+2. 把已经聊到的信息做汇总，方便 roadmap 技能接手不用重来。包含：
+   - 真问题 / 大致范围 / 已经提到的可能子模块（一句话各一）
+   - **如果聊到了跨模块的接口形态、共享协议、技术选型**——一并列出，这些是 roadmap ②"架构层详设"的种子，丢了就得重聊
 3. 本技能**不落盘**——`roadmap new` 模式会自己建 `codestable/roadmap/{slug}/` 目录和主文档，不需要 brainstorm 预留产物
 4. 告诉用户下一步触发 `cs-roadmap`
 
@@ -140,7 +143,7 @@ brainstorm 是"讨论层"的统一入口。用户开口时，AI 并不知道这
 
 - **一次只问一个问题**。一次抛三五个问题，用户大概率只回最容易答的那个，深的就漏了
 - **先给选项再提问**。能用 2-4 个具体、有区别度的选项让用户挑就别让用户自由作文——选项本身就是你的思考。环境支持 `AskUserQuestion` 就用，不支持用编号文本选项
-- **不在这一步做技术选型**。"用什么库、表怎么设计、接口怎么定"通通推到 design。本阶段只谈用户感知层面。如果某个问题的答案得看代码仓里实际怎么写（"现在这块是怎么做的"、"有没有类似的东西已经在了"），**按需去读代码**，读完把发现带回对话，别就着这个发现展开技术设计讨论
+- **不要主动把话题拉回"用户感知层面"**。用户想聊库、Schema、接口、技术选型，就跟着聊——TA 既然提出来，往往是心里已经有候选，讨论清楚后 design 直接落就好。AI 自己不要主动开技术细节话题去填时间，但用户开了的话题就认真陪聊，不要以"这个留给 design"为由打断。如果某个问题的答案得看代码仓里实际怎么写，**按需去读代码**，读完把发现带回对话
 
 ---
 
@@ -181,6 +184,11 @@ tags: [...]
 
 ### 方向 B / C ...
 
+## 已敲定的设计点
+{聊过程中已经达成共识的具体设计——库选型、Schema、接口形态、技术约束等。}
+{每条标注：已确认 / 倾向 / 待验证。design 阶段读到这里直接落，不再重新讨论。}
+{没聊到这一层就整节删掉，别留空 section}
+
 ## 选定方向与遗留问题
 {选定方向 2-3 句重述 + 粗粒度轮廓（核心行为、明显不做、最大未知）。遗留给 design 的问题直接列在这里}
 ```
@@ -193,11 +201,12 @@ frontmatter 字段口径跟 design / acceptance 共用一组（`doc_type` / `fea
 
 ## 退出
 
-按 case 各自的退出动作：
+按 case 各自的退出动作。退出时**告诉用户下一步触发哪个技能、它会读到哪份文件**——让用户切换技能时无须重述讨论：
 
-- **case 1**：告诉用户"直接触发 `cs-feat-design`"，不落盘，结束
-- **case 2**：收敛动作完成后主动问"这块够清楚了，可以进 design 了吗？"，用户确认后落盘 `{slug}-brainstorm.md`，告诉用户下一步触发 `cs-feat-design`
-- **case 3**：告诉用户"这次讨论移交给 `cs-roadmap` 做拆解"，带上已聊到的要点一句话汇总，不落盘，结束
+- **case 1（裸退）**：告诉用户"直接触发 `cs-feat-design`,从零开始写 design"，不落盘，结束
+- **case 1（带轻量落盘）**：聊过程里有非琐碎技术决策时，落 `codestable/features/{feature}/{slug}-brainstorm.md`（只填"已敲定的设计点"），告诉用户"下一步触发 `cs-feat-design`，它会读到 `{文件路径}`，不必重述"
+- **case 2**：收敛动作完成后主动问"这块够清楚了，可以进 design 了吗？"，用户确认后落盘 `{slug}-brainstorm.md`，告诉用户"下一步触发 `cs-feat-design`，它会读到 `{文件路径}`"
+- **case 3**：告诉用户"这次讨论移交给 `cs-roadmap` 做拆解"，附上聊到的要点汇总（含技术讨论部分），让用户触发 `cs-roadmap` 时直接复用，不落盘，结束
 
 **别自己顺手开始写 design 或 roadmap**——阶段间的人工 checkpoint 是 CodeStable 整套流程的硬约束。告诉用户下一步触发对应技能就够了。
 
@@ -208,8 +217,7 @@ frontmatter 字段口径跟 design / acceptance 共用一组（`doc_type` / `fea
 1. **不跳过分诊**——任何长度的讨论开始前都要先判 case，漏判会把用户带错出口
 2. **不替用户决定规模**——case 2 和 case 3 的边界有时模糊，拿不准就问用户"你脑子里这块是一个 feature 能装下的规模吗"，别自己选一个
 3. **不落盘非 case 2 产物**——case 1 / case 3 都不写文件，产物由下游负责
-4. **不做技术选型**——库、表、接口细节推到 design
-5. **不处理 bug / 重构**——走各自流程
+4. **不处理 bug / 重构**——走各自流程
 
 ---