一键导入
cs-brainstorm
// 想法还模糊时的讨论入口,做分诊后路由到 feature-design / feature-brainstorm / roadmap。AI 是思考伙伴不是记录员。触发:用户说"有个想法还没想清楚"、"先 brainstorm 一下"、"聊一聊这块"、"方向还在摇摆"。不处理 bug 和重构。
// 想法还模糊时的讨论入口,做分诊后路由到 feature-design / feature-brainstorm / roadmap。AI 是思考伙伴不是记录员。触发:用户说"有个想法还没想清楚"、"先 brainstorm 一下"、"聊一聊这块"、"方向还在摇摆"。不处理 bug 和重构。
通过 Chrome 扩展控制真实浏览器。需要访问网页、抽取网页数据、点击按钮、填写表单、执行浏览器自动化、提取渲染后的组件证据,或以程序方式操作页面时使用。通过 DOM diff、简化 HTML 和 component evidence pack 返回节省 token 的结构化结果。适用于 browser control、web automation、page scraping、web data extraction、execute JS in browser、web_scan、web_execute_js、open browser、navigate to URL、get page content、fill form、click button、extract component、rendered DOM、computed styles、component evidence。
feature 流程阶段 1——为新功能起草 {slug}-design.md 作为后续实现和验收的唯一输入,拍板后抽出 checklist。触发:用户说"开始设计方案"、"写 design doc"、"准备实现 XX",前提是已知道做什么、为谁、怎么算成功。
feature 流程的超轻量通道——不写 design / checklist 直接动手,但先指引 AI 查 CodeStable 知识库再开工。触发:用户说"快速模式"、"fastforward"、"别那么多步骤"、"直接开干",且需求小到不值得走 design 流程。
issue 流程阶段 2——读 report + 读代码定位根因、评估风险,给用户 2-3 个修复方案让 TA 拍板。这一步不改代码。触发:用户说"分析这个 bug"、"找根因"、"定位问题",且已有 {slug}-report.md。
系统审计——从代码中主动发现 bug 隐患、安全漏洞、性能问题、可维护性债务和架构偏离,产出批量发现清单。触发:用户说"审查系统"、"审计代码"、"扫描问题"、"找找 bug"、"有什么可以优化的"。
CodeStable 工作流根入口,介绍体系全貌并把诉求路由到对应 cs-* 子技能。触发:用户只输入 `cs`、说"介绍一下 codestable"、"该用哪个技能"、"不知道用哪个",或诉求还很开放未收敛。本技能只做路由不做事。
| name | cs-brainstorm |
| description | 想法还模糊时的讨论入口,做分诊后路由到 feature-design / feature-brainstorm / roadmap。AI 是思考伙伴不是记录员。触发:用户说"有个想法还没想清楚"、"先 brainstorm 一下"、"聊一聊这块"、"方向还在摇摆"。不处理 bug 和重构。 |
brainstorm 是"讨论层"统一入口。用户开口时 AI 不知道终点应落在哪——feature design / roadmap / 还是聊两句发现已经够清楚直接 design。本技能先用一两轮对话分诊,再把讨论交给合适下游。
三件最重要的事:
共享路径和命名约定看
codestable/reference/shared-conventions.md。
| case | 规模 | 用户状态 | 产物 |
|---|---|---|---|
| case 1:已经够清楚 | 不限 | 一句话能说清做什么 / 为谁 / 怎么算成功 / 不做什么 | 不落盘,直接 cs-feat-design |
| case 2:小需求 | 单 feature | 知道要解决什么问题,对解法 / 边界还摇摆 | codestable/features/{feature}/{slug}-brainstorm.md → cs-feat-design |
| case 3:大需求,拆解 ready | 多 feature | 心里已有大致模块划分,想直接做拆解和接口契约 | 不落盘,移交 cs-roadmap |
| case 4:大需求,想 grill | 多 feature | 还不想拆——想先 grill、发散、产生想法存着 | codestable/brainstorms/{slug}/brainstorm.md → 之后 cs-roadmap 读到 |
判错 case 不是灾难——允许升降级。case 2 聊着发现范围越聊越大切 case 3/4,case 3 聊着发现需要先 grill 切 case 4,case 4 grill 完可以直接拆切 case 3,当场切换出口。
每次都做:
AGENTS.md;Glob codestable/ 发现 architecture / features / roadmap / brainstorms / compound / requirements,读架构总入口、看已有 feature 和 roadmap 和 brainstorm、搜 compound 看有没有相关坑(--filter doc_type=learning);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 档硬约束(防止没完没了):
发散——确认问题后再谈方案。提 2-3 个具体候选方向(用户带的方案算其中一个),每个 1-2 句描述 / 价值 / 代价。至少有一个反直觉候选(反转 / 去掉常见约束 / 跨领域类比)。所有候选呈现完再给推荐——先锚定再补别的会污染用户判断
收敛——选定方向后轻轻勾勒:核心行为?明显不做?最大未知?给 design 热身不是替 design 决定
讨论中冒出"这个方向能不能走得通要看 X 实际是不是 Y"——不要靠脑补辩论,停下来花 5-30 分钟搭个最小 demo 验一下比再聊三轮更省时。
默认不做——大多数 brainstorm 是在比较权衡,demo 帮不上忙。同时满足下面三条才主动提议:
cs-feat-ff 直接做或拆成正式 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),逻辑一样:事实存疑 + 改变方向 + 成本可控。
信号:一句话能说出做什么 / 为谁 / 怎么算成功 / 不做什么;聊两句核心行为 / 成功标准都对上。
处理:
cs-feat-design——brainstorm 对你没增量"退出:"直接触发 cs-feat-design 从零写 design"(不落盘);轻量落盘则"下一步 cs-feat-design 会读到 {路径} 不必重述"
信号:知道要解决什么问题、大致做哪块,一个 feature 能装下,但对解法 / 边界还摇摆。
怎么聊:按上节"怎么聊"工具箱推进——挖问题 → 发散 → 收敛。收敛到选定方向后落盘。
升降级:
落盘:收敛完成后写 codestable/features/{feature}/{slug}-brainstorm.md。
目录约定:
只在用户确认进 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 节。
退出:主动问"这块够清楚了可以进 design 吗?",确认后落盘,告诉用户"下一步 cs-feat-design 会读到 {路径}"
信号:多 feature 规模,用户心里已有大致模块划分,能说出拆法,想直接做拆解和接口契约。
处理:
cs-roadmap 会做拆解和依赖梳理,我把讨论交给它"roadmap new 自己建目录和主文档退出:"移交给 cs-roadmap"(附聊到的要点汇总),不落盘
信号:多 feature 规模,但用户说不清模块边界、想先发散探索——"帮我问问清楚"、"先把想法理一理存着"、"方向还乱,聊开了再说"。
这是创意空间,不是设计文档。目标是产生可留存的想法、方向和洞察,供后续 roadmap 消费。
怎么聊:启动 grill 档(见上节"对话节奏 > grill 档"),同时自由发散——聊方案、聊类比、聊技术可能性、聊限制。对话比 case 2 更开放,不急着收敛。
升降级:
落盘:用户说"先这样"/"差不多了"/"存一下",或 AI 判断 grill 已到 3-5 轮上限,主动说"这块我先帮你落到 brainstorms 里,之后 roadmap 会读到"。
路径:codestable/brainstorms/{slug}/
codestable/brainstorms/{slug}/
└── brainstorm.md 创意记录
目录不存在就创建。slug 根据方向自拟英文小写连字符。
---
doc_type: brainstorm
slug: {slug}
created: YYYY-MM-DD
status: active
summary: 一句话讲这块要探索什么
tags: [...]
---
# {主题名}
> 创意空间 | {YYYY-MM-DD} | 下一步:cs-roadmap
## 出发点
{什么触发了这个想法 / 想解决什么问题 / 为什么觉得值得做}
## 聊过的方向
{发散过程的关键转折、候选方向、讨论过的可能性——不要求收敛,保留探索痕迹}
## 当前倾向
{聊到目前的模糊方向——可以是 2-3 个还在摇摆的方向,各自一两句}
{如果已经比较清楚,写"倾向于 X 方向,核心是 Y"}
## 已敲定的点
{聊过程中已经达成共识的——哪怕只是一个约束、一个不做、一个类比}
{什么都没有就删掉这节}
## 遗留问题 & 下一步
{最大的未知 / 需要验证的假设 / 建议 roadmap 注意的点}
doc_type: brainstorm 区别于 case 2 的 feature-brainstorm和 roadmap 的衔接:cs-roadmap 启动时会搜 codestable/brainstorms/ 看有没有相关 brainstorm。如果有,roadmap 把 brainstorm 当输入材料读,不重复分诊直接拆。
退出:落盘后告诉用户"想法存到 {路径} 了,准备好了就触发 cs-roadmap,它会读到这份脑暴记录"