cs-brainstorm

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

cs-brainstorm

brainstorm 是"讨论层"的统一入口。用户开口时，AI 并不知道这次讨论的终点应该落在哪——是一份 feature design、一份 roadmap，还是聊两句就发现已经够清楚可以直接去 design。本技能先用一两轮对话做分诊，然后把讨论交给合适的下游。

两件最重要的事：

brainstorm 是创意空间，不是审计关卡。在这里探索、质疑、改变主意、聊着聊着发现真正想做的是另一件事——都正常。约束和落地细节留给下游技能。
AI 是思考伙伴，不是记录员。用户来这一步是想被挑战、被启发，不是来被一条条问题填表的。如果你只是把用户的话整理一遍写下来，那这一步就白做了。

共享路径和命名约定看
codestable/reference/shared-conventions.md
。

cs-brainstorm is the unified entry point for the "discussion layer". When a user initiates a conversation, the AI doesn't know where the discussion should end up — whether it's a feature design, a roadmap, or realizing after a few exchanges that the idea is clear enough to proceed directly to design. This skill first conducts triage through 1-2 rounds of dialogue, then transfers the discussion to the appropriate downstream process.

Two most important things:

Brainstorm is a creative space, not an audit checkpoint. It's normal to explore, question, change your mind, or realize you actually want to do something else during the discussion. Leave constraints and implementation details to downstream skills.
AI is a thinking partner, not a recorder. Users come to this step to be challenged and inspired, not to answer a list of questions like filling out a form. If you just organize and write down what the user says, this step is pointless.

See
codestable/reference/shared-conventions.md
for shared paths and naming conventions.

三种讨论、三个出口

Three Discussion Scenarios, Three Exit Paths

用户带来的问题大致落在三种情况里，各自的正确出口不一样：

情况	特征	出口
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 聊着聊着发现用户真正要的只是一个小 feature（范围收窄），当场告诉用户切换出口，不要硬着头皮继续。

The problems users bring roughly fall into three scenarios, each with a correct exit path:

Scenario	Characteristics	Exit Path
Case 1: Already clear enough	Can state clearly in one sentence "what to do / who it's for / how to define success / what explicitly not to do", no further exploration needed	Directly proceed to `cs-feat-design` (this skill does not document anything; inform the user and stop)
Case 2: Small requirement, direction set but details vague	Knows the problem to solve and the general area, but is uncertain about the real problem / solution approach / boundaries; can fit into a single feature	Discuss and document in `{slug}-brainstorm.md` under `codestable/features/{feature}/` , then proceed to `cs-feat-design`
Case 3: Large requirement, only a high-level concept	Says "I want an X system / a set of Y capabilities", which can be foreseen to be split into multiple features, or even the minimum viable loop is unclear	Transfer to `cs-roadmap` (this skill does not document anything; hand over the discussion)

Misclassifying a scenario is not a disaster — upgrading or downgrading is allowed. If during a Case 2 discussion you realize it's actually Case 3 (scope expands as you talk), or during Case 3 you find the user only needs a small feature (scope narrows), inform the user immediately to switch exit paths instead of forcing the discussion to continue.

开聊之前先做的检查

Pre-Discussion Checks

五件事，每次都做：

扫一眼仓库——第一次提问之前完成这几件：读
```
AGENTS.md
```
+
```
codestable/architecture/DESIGN.md
```
；Glob
```
codestable/features/
```
已有目录；Glob
```
codestable/roadmap/
```
已有子目录；Grep 用户描述里的关键词（防术语冲突）；搜
```
codestable/compound/
```
看有没有相关的踩坑记录（
```
--filter doc_type=learning
```
）。扫完在对话里简短报告发现，让用户知道你不是凭空在跟 TA 聊。
是不是接续之前的工作——
```
codestable/features/
```
下有名字相近的
```
{slug}-brainstorm.md
```
吗？
```
codestable/roadmap/
```
下有名字相近的子目录吗？
- 没有 → 当新讨论
- 有
```
{slug}-brainstorm.md
```
  ，内容是对话中断留下的 → 读完简短汇报"上次聊到了 {选定方向 / 最后那个话题}，接着聊还是推翻重来？"
- 有同名
```
{slug}-design.md
```
  → 告诉用户 design 已经开了，是不是走错入口
- 有同名 roadmap 子目录 → 告诉用户这块已经在 roadmap 里跟进，是不是要推进具体子 feature
确认这是新功能 brainstorm——bug 走
```
cs-issue
```
，重构走
```
cs-refactor
```
。走错入口比拒绝触发还坏。
开场判 case（下一节展开）——这是本技能的核心动作。
如果你已经能替用户写出 design 第 1 节需求摘要的初稿——老实告诉用户"我感觉你已经够清楚了，直接进 feature-design 更省事"，也就是当场判 case 1。揽下不属于自己的活是本阶段最大的反模式。

Five things to do every time:

Scan the repository — complete these before the first question: read
```
AGENTS.md
```
+
```
codestable/architecture/DESIGN.md
```
; list existing directories under
```
codestable/features/
```
; list existing subdirectories under
```
codestable/roadmap/
```
; grep keywords from the user's description (to avoid term conflicts); search
```
codestable/compound/
```
for relevant learning records (
```
--filter doc_type=learning
```
). Briefly report your findings in the conversation so the user knows you're not talking out of thin air.
Is this a continuation of previous work — is there a similar-named
```
{slug}-brainstorm.md
```
under
```
codestable/features/
```
? Is there a similar-named subdirectory under
```
codestable/roadmap/
```
?
- No → Treat as a new discussion
- Yes,
```
{slug}-brainstorm.md
```
  exists with content from an interrupted conversation → After reading, briefly report: "Last time we talked about {selected direction / last topic}. Should we continue or start over?"
- Yes, a同名
```
{slug}-design.md
```
  exists → Tell the user that design has already started, and ask if they entered the wrong entry point
- Yes, a同名 roadmap subdirectory exists → Tell the user this area is already being tracked in the roadmap, and ask if they want to advance specific sub-features
Confirm this is a brainstorm for new features — bugs go to
```
cs-issue
```
, refactoring goes to
```
cs-refactor
```
. Entering the wrong entry point is worse than refusing to trigger the skill.
Classify the scenario at the start (detailed in the next section) — this is the core action of this skill.
If you can already draft the requirement summary (Section 1 of design) for the user — honestly tell the user: "I think you're clear enough already; it's more efficient to go directly to feature-design", which means classifying it as Case 1 on the spot. Taking on work that doesn't belong to this stage is the biggest anti-pattern here.

开场分诊：一两轮对话判 case

Initial Triage: Classify Scenarios in 1-2 Rounds of Dialogue

分诊的目的是尽快把这次讨论交给对的下游。不是填表——问太多分类题会让用户觉得在走官僚流程。

The goal of triage is to transfer the discussion to the correct downstream process as soon as possible. This is not form-filling — asking too many classification questions will make the user feel like they're going through bureaucratic procedures.

分诊的问法

How to Conduct Triage

两种开场，按用户开口的方式选一种：

用户只说了一个模糊的词 / 短句（"我想要一个权限系统"、"想聊聊通知"、"有个想法"）：

一句话先对齐：你想解决的是 {AI 复述的问题} 对吧？如果是的话，这块你脑子里是多大的范围——是"改一处 / 加一个小能力"那种一个 feature 能装下的，还是"一整块新子系统，得分几轮做"的规模？

用户回答就基本能判出 case 2 还是 case 3。

用户带着方案来（"我想做一个 X，里面有 a/b/c"）：

先让我复述一下看对不对——你想解决的问题是 {P}，打算做 X 包含 a/b/c 来解。这里 a/b/c 合起来更像一个 feature 能搞定的一件事，还是三件互相有依赖的事要分几轮做？

如果用户自己把方案拆成多件——八成是 case 3；如果 a/b/c 其实是同一件事的不同面，八成是 case 2；如果用户听完复述说"对就是这个我想清楚了"——case 1，让 TA 直接去 design。

Two opening approaches, choose one based on how the user initiates the conversation:

User only says a vague word / short phrase ("I want a permission system", "Want to talk about notifications", "I have an idea"):

Align first in one sentence: You want to solve {AI's restated problem}, right? If yes, what's the scope in your mind — is it something that can fit into a single feature like "modify one part / add a small capability", or is it a whole new subsystem that needs to be done in multiple rounds?

The user's answer will basically let you classify it as Case 2 or Case 3.

User comes with a solution ("I want to build X, which includes a/b/c"):

Let me restate this to check if I understand correctly — you want to solve problem {P}, and plan to build X with a/b/c to solve it. Do a/b/c together look like one thing that can be handled by a single feature, or three interdependent things that need to be done in multiple rounds?

If the user splits the solution into multiple parts — it's most likely Case 3; if a/b/c are actually different aspects of the same thing — it's most likely Case 2; if the user says "Yes, that's it, I'm clear" after hearing the restatement — it's Case 1, tell them to go directly to design.

不要强行收敛

Don't Force Convergence

用户说不清楚自己属于哪种——不要让 TA 在"case 2 还是 case 3"里选。继续聊一两轮挖真问题，AI 自己判断。以下信号帮 AI 判 case：

聊出来的每一条目标，都是同一件事的不同角度 → case 2
聊出来几条目标之间有先后依赖或互相独立的子模块 → case 3
聊两句发现"不做什么"、"核心行为"、"成功标准"都能对上 → case 1

If the user can't clearly define which scenario they're in — don't make them choose between "Case 2 or Case 3". Continue the conversation for 1-2 more rounds to dig out the real problem, and the AI will make the judgment. The following signals help the AI classify the scenario:

Every goal discussed is a different angle of the same thing → Case 2
Multiple goals discussed have sequential dependencies or independent sub-modules → Case 3
After a few exchanges, you find that "what not to do", "core behaviors", and "success criteria" are all clear → Case 1

三种 case 各自怎么处理

How to Handle Each Scenario

case 1：其实已经够清楚

Case 1: Already Clear Enough

动作：

告诉用户"这块你已经想清楚了：{AI 一句话复述做什么 / 为谁 / 怎么算成功 / 明确不做}。建议直接走
```
cs-feat-design
```
——brainstorm 对你没增量价值"
本技能不落盘——没产出
```
{slug}-brainstorm.md
```
，也不建 feature 目录（design 阶段会建）
停下来，等用户触发 design

为什么这样处理？brainstorm 的价值在"把模糊聊清楚"，模糊没了这步就是负担。硬凑一份 brainstorm note 会让后人以为这里真发生过有价值的讨论。

Actions:

Tell the user: "You've already clarified this: {AI's one-sentence restatement of what to do / who it's for / how to define success / what explicitly not to do}. It's recommended to go directly to
```
cs-feat-design
```
— brainstorm won't add any value for you"
This skill does not document anything — no
```
{slug}-brainstorm.md
```
is produced, and no feature directory is created (this will be done in the design stage)
Stop and wait for the user to trigger design

Why handle it this way? The value of brainstorm is "clarifying vague ideas"; if there's no vagueness left, this step becomes a burden. Forcing a brainstorm note will make future readers think a valuable discussion took place here.

case 2：小需求，在 feature 里继续讨论

Case 2: Small Requirement, Continue Discussion in Feature

进入当前阶段 0 对话模式。按"怎么聊（case 2 展开）"一节的姿态往下推进，收敛后落盘

codestable/features/{feature}/{slug}-brainstorm.md

。

Enter the current Stage 0 dialogue mode. Proceed according to the guidelines in the "How to Discuss (Case 2 Details)" section, and after convergence, document in

codestable/features/{feature}/{slug}-brainstorm.md

case 3：大需求，移交给 roadmap

Case 3: Large Requirement, Transfer to Roadmap

动作：

告诉用户"这块听起来是多个 feature 的集合，单个 feature 装不下。brainstorm 对这种规模的讨论不是好入口——
```
cs-roadmap
```
会做拆解和依赖梳理，我现在把讨论交给它比较合适"
把已经聊到的信息做一句话汇总（真问题 / 大致范围 / 已经提到的可能子模块），方便 roadmap 技能接手不用重来
本技能不落盘——
```
roadmap new
```
模式会自己建
```
codestable/roadmap/{slug}/
```
目录和主文档，不需要 brainstorm 预留产物
告诉用户下一步触发
```
cs-roadmap
```

为什么不在本技能里做大需求讨论？大需求的讨论价值几乎全在"拆成几块 / 依赖怎么走 / 最小闭环选哪条"，这套思考 roadmap 自己带——单独在 brainstorm 里聊一轮会和 roadmap 重复做一遍。

Actions:

Tell the user: "This sounds like a collection of multiple features that can't fit into a single feature. Brainstorm is not a good entry point for discussions of this scale —
```
cs-roadmap
```
will handle decomposition and dependency sorting. It's more appropriate to transfer the discussion to it now"
Summarize the information already discussed in one sentence (real problem / general scope / possible sub-modules mentioned) to help the roadmap skill take over without starting from scratch
This skill does not document anything — the
```
roadmap new
```
mode will create the
```
codestable/roadmap/{slug}/
```
directory and main document on its own; no reserved output from brainstorm is needed
Tell the user to trigger
```
cs-roadmap
```
next

Why not discuss large requirements in this skill? The value of discussing large requirements lies almost entirely in "splitting into parts / defining dependencies / choosing the minimum viable loop", which is already handled by the roadmap skill — discussing it separately in brainstorm would duplicate the work done by roadmap.

怎么聊（case 2 展开）

How to Discuss (Case 2 Details)

确认走 case 2 之后进入以下对话模式。case 1 / case 3 不适用本节。

After confirming to proceed with Case 2, enter the following dialogue mode. This section does not apply to Case 1 / Case 3.

两条核心姿态

Two Core Principles

这两条比下面任何一条操作建议都重要。

1. 区分"用户说的"和"用户要的"。用户开口的第一句话往往是 TA 已经想到的方案，不是 TA 真正要解决的问题。听到"我想做一个 X"先别顺着 X 往下聊方案细节，先问"X 是为了解决什么场景下的什么问题"。常见的发现是：真问题不是 X 能解决的，或者有更小、更轻、完全不同方向的解法。一旦进了 design，方向就基本焊死——在用户自己还没意识到之前完成这件事是 brainstorm 阶段最大的价值。

2. 用户带着方案来时，先评估再接受。当用户给的不是模糊想法而是已经成型的方案（"我想做一个 X，包含 a/b/c"），不要直接进入"那我们聊聊 a 怎么做"。先做这两步：

复述 + 反向追问问题：把方案翻成"你想解决的问题是不是 P"，让用户确认或修正
评估并提替代：如果你看到这个方案有明显的问题（解错了问题、过度工程、有现成更轻的路径、踩 learning 文档里的坑），直接说出来，并提 1-2 个明显不同的替代方向让用户对比。不要为了显得配合就闭嘴——这是用户来 brainstorm 的本意

评估完发现方案确实合理，明确告诉用户"我觉得这个方向 OK，建议直接进 design"，别为了凑流程硬发散——这就是当场升级到 case 1。

These two principles are more important than any operational suggestions below.

1. Distinguish between "what the user says" and "what the user needs". The user's first sentence is often a solution they've already thought of, not the real problem they want to solve. When you hear "I want to build X", don't immediately discuss the details of X; first ask "What problem in what scenario is X intended to solve?" A common finding is: the real problem can't be solved by X, or there's a smaller, lighter, completely different solution. Once you enter the design stage, the direction is basically fixed — doing this before the user realizes it themselves is the greatest value of the brainstorm stage.

2. When the user comes with a solution, evaluate first before accepting. When the user provides a formed solution instead of a vague idea ("I want to build X, which includes a/b/c"), don't immediately jump into "Let's talk about how to do a". First do these two steps:

Restate + reverse question: Translate the solution into "Is the problem you want to solve P?" and let the user confirm or correct it
Evaluate and propose alternatives: If you see obvious problems with the solution (solves the wrong problem, over-engineering, there's a lighter existing path, it repeats mistakes in learning documents), point them out directly and propose 1-2 distinctly different alternative directions for the user to compare. Don't stay silent just to be cooperative — this is why the user came to brainstorm.

If after evaluation you find the solution is reasonable, clearly tell the user: "I think this direction is OK; it's recommended to go directly to design". Don't force divergence just to follow the process — this means upgrading to Case 1 on the spot.

对话节奏

Dialogue Rhythm

没有固定步骤表。大致分三个动作，随时可以回到上一步：

挖问题——按姿态 1 把"真正要解决的问题"问清楚。问到你能用一句话复述出问题、并且用户说"对就是这个"为止。这一步是 brainstorm 价值最高的一步，不要急着跳过
发散——确认问题之后再谈方案。提议 2-3 个具体的候选方向（用户带了方案的话 TA 的方案算其中一个），每个写 1-2 句描述、核心价值、主要代价。至少有一个反直觉候选（反转一下、去掉一个常见约束、做个跨领域类比）。所有候选呈现完再给推荐——先锚定一个再补充别的，用户的判断会被你的开场白污染
收敛——用户选定方向后轻轻勾勒：核心用户行为是什么？明显不做什么？最大的未知是什么？这是给 design 热身，不是替 design 做决定，别陷进细节

There's no fixed step-by-step process. It roughly consists of three actions, and you can go back to the previous step at any time:

Dig out the problem — follow Principle 1 to clarify the "real problem to solve". Keep asking until you can restate the problem in one sentence and the user says "Yes, that's it". This is the most valuable step in brainstorm; don't rush to skip it
Diverge — discuss solutions only after confirming the problem. Propose 2-3 specific candidate directions (if the user brought a solution, theirs counts as one). For each, write 1-2 sentences describing it, its core value, and main costs. Include at least one counterintuitive candidate (reverse something, remove a common constraint, make a cross-domain analogy). Give recommendations only after presenting all candidates — if you anchor one first and then add others, the user's judgment will be biased by your opening
Converge — after the user selects a direction, outline lightly: What are the core user behaviors? What explicitly won't be done? What's the biggest unknown? This is a warm-up for design, not making decisions for design; don't get stuck in details

随时升降级

Upgrade/Downgrade Anytime

对话中途信号变了就换 case：

聊着发现其实是大需求（子模块越聊越多、有依赖关系）→ 当场告诉用户"这规模超出单 feature，建议切到 roadmap"，按 case 3 动作移交
聊两句发现其实全都清楚了 → "我觉得已经够进 design 了"，按 case 1 动作停下

If signals change during the dialogue, switch scenarios:

If you realize it's actually a large requirement (more sub-modules are discussed, there are dependencies) → Immediately tell the user: "This scale exceeds a single feature; it's recommended to switch to roadmap" and transfer according to Case 3 actions
If you realize everything is clear after a few exchanges → "I think we're ready to enter design" and stop according to Case 1 actions

常见的坑

Common Pitfalls

一次只问一个问题。一次抛三五个问题，用户大概率只回最容易答的那个，深的就漏了
先给选项再提问。能用 2-4 个具体、有区别度的选项让用户挑就别让用户自由作文——选项本身就是你的思考。环境支持
```
AskUserQuestion
```
就用，不支持用编号文本选项
不在这一步做技术选型。"用什么库、表怎么设计、接口怎么定"通通推到 design。本阶段只谈用户感知层面。如果某个问题的答案得看代码仓里实际怎么写（"现在这块是怎么做的"、"有没有类似的东西已经在了"），按需去读代码，读完把发现带回对话，别就着这个发现展开技术设计讨论

Ask only one question at a time. If you throw 3-5 questions at once, the user will most likely only answer the easiest one, and deeper issues will be missed
Provide options before asking a question. If you can use 2-4 specific, distinct options for the user to choose from, don't let them write freely — the options themselves are your thinking. Use
```
AskUserQuestion
```
if the environment supports it; if not, use numbered text options
Don't make technical selections at this stage. All decisions like "which library to use, how to design tables, how to define interfaces" are pushed to design. This stage only discusses user-perceived aspects. If the answer to a question depends on how things are actually implemented in the code repository ("How is this done now?", "Is there something similar already?"), read the code as needed, bring your findings back to the conversation, but don't expand into technical design discussions based on those findings

case 2 落盘

Documenting for Case 2

收敛动作完成后写 brainstorm note 到

codestable/features/{feature}/{slug}-brainstorm.md

。

After completing the convergence action, write the brainstorm note to

codestable/features/{feature}/{slug}-brainstorm.md

feature 目录怎么建

How to Create the Feature Directory

日期前缀：从环境信息里取今天的日期
slug：根据选定方向自拟英文小写连字符 slug，写进 note 时顺便告诉用户一声。用户有异议再改，不用专门起一轮"slug 叫什么"的对话。design 阶段改名只 rename slug 部分，日期前缀别动，整个目录一起 rename
目录不存在就创建；已存在回到"开聊之前先做的检查"第 2 条

Date prefix: Take today's date from the environment information
Slug: Create a lowercase English hyphenated slug based on the selected direction, and inform the user when writing the note. Modify it only if the user has objections; no need for a dedicated conversation about "what to name the slug". When renaming in the design stage, only rename the slug part; keep the date prefix unchanged, and rename the entire directory together
Create the directory if it doesn't exist; if it does exist, go back to Item 2 of "Pre-Discussion Checks"

brainstorm note 模板

Brainstorm Note Template

brainstorm note 只在用户确认进 design 那一刻落盘——对话期间什么都不写到文件里。所以模板里

status

固定为

confirmed

，没有

draft

状态。

markdown

---
doc_type: feature-brainstorm
feature: YYYY-MM-DD-{slug}
status: confirmed
summary: 一句话讲选定方向是什么
tags: [...]
---

The brainstorm note is only documented when the user confirms entering design — nothing is written to the file during the dialogue. Therefore, the

status

in the template is fixed as

confirmed

, with no

draft

status.

markdown

---
doc_type: feature-brainstorm
feature: YYYY-MM-DD-{slug}
status: confirmed
summary: One-sentence description of the selected direction
tags: [...]
---

{功能名称} Brainstorm

{Feature Name} Brainstorm

Stage 0 | {YYYY-MM-DD} | 下一步：design

Stage 0 | {YYYY-MM-DD} | Next step: design

想做什么、为什么

What to Do and Why

{出发点 + 探索中的关键发现和转折，合在一起讲}

{Combine the starting point + key discoveries and turning points during exploration}

考虑过的方向

Considered Directions

方向 A：{名}

Direction A: {Name}

描述 / 价值 / 代价
结论：选定 / 否决（原因）

Description / Value / Cost
Conclusion: Selected / Rejected (reason)

方向 B / C ...

Direction B / C ...

选定方向与遗留问题

Selected Direction and Outstanding Issues

{选定方向 2-3 句重述 + 粗粒度轮廓（核心行为、明显不做、最大未知）。遗留给 design 的问题直接列在这里}


frontmatter 字段口径跟 design / acceptance 共用一组（`doc_type` / `feature` / `status` / `summary` / `tags`），看 `codestable/reference/shared-conventions.md` 第 1 节。

仓库扫描发现、术语冲突提示、learning 文档引用这类备注按需加在末尾，不另开 section。

---

{2-3 sentences restating the selected direction + high-level outline (core behaviors, explicitly not doing, biggest unknowns). List issues left for design directly here}


The frontmatter fields use the same specifications as design / acceptance (`doc_type` / `feature` / `status` / `summary` / `tags`). See Section 1 of `codestable/reference/shared-conventions.md`.

Add notes such as repository scan findings, term conflict reminders, and learning document references at the end as needed; no separate section is required.

---

退出

Exit

按 case 各自的退出动作：

case 1：告诉用户"直接触发
```
cs-feat-design
```
"，不落盘，结束
case 2：收敛动作完成后主动问"这块够清楚了，可以进 design 了吗？"，用户确认后落盘
```
{slug}-brainstorm.md
```
，告诉用户下一步触发
```
cs-feat-design
```
case 3：告诉用户"这次讨论移交给
```
cs-roadmap
```
做拆解"，带上已聊到的要点一句话汇总，不落盘，结束

别自己顺手开始写 design 或 roadmap——阶段间的人工 checkpoint 是 CodeStable 整套流程的硬约束。告诉用户下一步触发对应技能就够了。

Follow the exit actions for each scenario:

Case 1: Tell the user "Trigger
```
cs-feat-design
```
directly", do not document anything, and end
Case 2: After completing the convergence action, proactively ask "Is this clear enough to enter design?" After the user confirms, document in
```
{slug}-brainstorm.md
```
, and tell the user to trigger
```
cs-feat-design
```
next
Case 3: Tell the user "This discussion is transferred to
```
cs-roadmap
```
for decomposition", include a one-sentence summary of the key points discussed, do not document anything, and end

Do not start writing design or roadmap on your own — manual checkpoints between stages are hard constraints of the entire CodeStable process. It's enough to tell the user to trigger the corresponding skill next.

硬性边界

Hard Boundaries

不跳过分诊——任何长度的讨论开始前都要先判 case，漏判会把用户带错出口
不替用户决定规模——case 2 和 case 3 的边界有时模糊，拿不准就问用户"你脑子里这块是一个 feature 能装下的规模吗"，别自己选一个
不落盘非 case 2 产物——case 1 / case 3 都不写文件，产物由下游负责
不做技术选型——库、表、接口细节推到 design
不处理 bug / 重构——走各自流程

Do not skip triage — classify the scenario before starting any discussion, regardless of length; missing triage will lead the user to the wrong exit path
Do not decide the scale for the user — the boundary between Case 2 and Case 3 is sometimes vague; if unsure, ask the user "Is this something that can fit into a single feature in your mind?" instead of making the choice yourself
Do not document anything for non-Case 2 scenarios — no files are written for Case 1 / Case 3; outputs are handled by downstream processes
Do not make technical selections — details about libraries, tables, and interfaces are pushed to design
Do not handle bugs / refactoring — follow their respective processes

常见错误

Common Mistakes

跳过分诊直接按老模板走：默认所有讨论都按 case 2 推进，大需求被硬塞进一个 feature
分诊问得太多像问卷：case 判断不是填表，一两轮对话就该有方向；问到第三轮还在对齐规模说明方法错了
case 1 硬凑 brainstorm note：用户已经清楚了还写一份模板给 design 做输入——后人打开会误以为这里发生过有价值的讨论
case 3 自己做拆解：在本技能里把大需求拆成多个 feature 清单，越俎代庖——那是 roadmap 的产物
升降级信号出现不理：明明聊着范围扩大了还在继续 case 2 对话，最后落盘一份塞不下所有子模块的 brainstorm note
一次只给一个方案让用户评价：用户被锚定，提不出别的方向
复述用户方案就落盘：记录员心态，AI 没提供思考伙伴的价值

Skipping triage and following the old template directly: Defaulting all discussions to proceed as Case 2, forcing large requirements into a single feature
Asking too many triage questions like a questionnaire: Scenario classification is not form-filling; you should have a direction after 1-2 rounds of dialogue; if you're still aligning the scale in the third round, your method is wrong
Forcing a brainstorm note for Case 1: Writing a template as input for design even though the user is already clear — future readers will mistakenly think a valuable discussion took place here
Decomposing large requirements in this skill: Listing multiple features for a large requirement in this skill, overstepping boundaries — this is the output of the roadmap skill
Ignoring upgrade/downgrade signals: Continuing the Case 2 dialogue even though the scope is expanding, finally documenting a brainstorm note that can't fit all sub-modules
Providing only one solution for the user to evaluate: The user is anchored and can't propose other directions
Documenting just by restating the user's solution: Having a recorder mindset, the AI doesn't provide the value of a thinking partner