bm-brainstorming

name	bm.brainstorming
description	动手前精炼意图：用苏格拉底式追问把模糊需求变成清晰 spec，分块呈现给用户确认后再开干。Use when user has a vague idea, fuzzy goal, or complex request that needs sharpening, 想做, 想要, 计划, 设计, 帮我做, 帮我想, brainstorm, idea, plan, spec, design. 写文章/做决策/做计划/写代码前都适用。
source	opencrew
version	20260521.01

Skill: Brainstorming（动手前精炼意图）

写代码/写文章/做决策之前，先把模糊的想法磨成明确的 spec，让用户确认每一块再继续。受众非技术，写文章、定计划、做产品决策都可以用。

---

何时触发

用户给的需求是模糊或多解的，比如：

• "帮我写个 X" → X 是什么？给谁看？目标是什么？
• "我想做个 Y 工具/产品/活动" → 解决什么问题？目标用户？范围？
• "帮我想想 Z" → 想清楚什么？已有什么约束？
• "重构/优化/整理 W" → 现状哪里不满意？理想状态什么样？

不要触发的情况：用户给的是清晰、可直接执行的指令（"把 README 第二段改成 XXX"、"装一下 ffmpeg"）。

---

核心流程

Step 1：识别模糊点（不要立刻动手）

读用户的输入，列出 3-5 个最关键的不确定项。优先级：

1. 目标：这件事做完，要达到什么状态？成功标准是什么？
2. 受众/用户：谁会看/用这个？他们的背景和期待？
3. 范围：什么必须有，什么不必有，什么坚决不做？
4. 约束：时间、预算、技术、风格上的硬限制？
5. 已有素材：用户手头有什么参考、半成品、相关资料？

Step 2：苏格拉底式追问

一次只问 1-2 个最关键的问题。不要一次甩 10 个问题，用户会烦。

问题原则：

• 具体：不问"你想要什么风格"，问"你希望像 A 那样还是像 B 那样？给个例子"
• 二选一/多选一：减少用户脑力负担
• 基于猜测：先猜一个答案给用户验证（"我理解你是想 X，对吗？"）

例子：

❌ 差："你想做个什么样的产品？" ✅ 好："这个工具是给你自己用，还是要给别人用？如果给别人，是同事还是付费用户？"

❌ 差："文章风格怎么定？" ✅ 好："这篇文章是想严肃论证（像学术）还是想吸引注意力（像公众号）？我倾向后者，因为你提到要发朋友圈。"

Step 3：分块呈现 spec（关键）

不要一次呈现完整的长 spec，分块给用户看：

我的理解（请确认或纠正）：

【目标】
- 成功标准：XXX

【受众】
- 主要：YYY
- 次要：ZZZ

⏸️ 这两块对吗？我先确认这个，再继续问范围和约束。

用户确认 → 继续下一块。用户纠正 → 改完再确认 → 继续。

Step 4：完整 spec 落盘

确认完所有块后，写入 ./working/brainstorm-{topic}.md（中间产物）或 ./{topic}-spec.md（最终产物）：

# Spec: {主题}

## 目标
- 成功标准：...

## 受众
- 主要：...

## 范围
- 必须有：...
- 不做：...

## 约束
- 时间：...
- 风格：...

## 已有素材
- ...

## 下一步
- [ ] ...

Step 5：明确交接

Spec 已落到 ./{topic}-spec.md，确认无误我就开始动手。

---

反模式（不要这样）

反模式	为什么错	正确做法
直接开干	走偏的代价 = 全部返工	先 spec 后干
一次问 10 个问题	用户被吓跑	一次 1-2 个，分块走
给开放式问题	用户不知怎么答	给具体选项或猜测让用户确认
一次甩完整 spec	太长，用户读不完不会逐块校对	分块，每块停一下
只问不猜	像审讯，用户烦	先猜一个版本让用户改
用户一句"差不多"就开干	模糊点没解决	卡住的关键点必须明确

---

三档触发深度

按需求复杂度选档：

档位	适用	工作量
轻量	简单需求只有 1-2 个模糊点	直接问 1 句，得到答案就动手，不写 spec 文件
标准	中等复杂度，需要确认目标+范围	完整走 Step 1-5，spec 写到 working/
深度	大项目、产品、长内容	标准基础上加竞品/参考调研，spec 写到根目录归档

模糊时主动问用户："这是想快速对齐一下，还是要做个完整的 spec？"

---

与其他 skill 的协作

• 完成 spec 后，真正动手前：调用 bm.voice-of-user 从用户视角拷问一遍
• 完成执行后：调用 bm.verification 自验证是否达成 spec 里的成功标准
• 写文章/报告：spec 落盘后用 skilless.ai-writing 执行
• 调研需求：spec 落盘后用 skilless.ai-research 或 bm.research

---

文件落点

• 中间 brainstorm 草稿 → ./working/brainstorm-{topic}.md
• 最终 spec → ./{topic}-spec.md 或用户指定位置
• 不写 /tmp/、不用隐藏目录