---
name: blade-storm
description: >
  BladeX 协作式头脑风暴与设计探索工具。通过渐进式提问将模糊想法精炼为可落地的技术方案。
  当用户说"我有个想法"、"帮我想想怎么做"、"我想做个XX功能"、"头脑风暴"、"brainstorm"、
  "讨论一下方案"、"我在考虑"、"这个需求怎么设计"、"帮我分析一下思路"、"这个方案你怎么看"等时触发。
  即使用户只是模糊地描述一个想法或问"XX能不能做"、"XX合不合理"也应触发。
  也可直接使用 /blade-storm 调用。适用于功能设计初期的发散思考与方案收敛，
  不适用于已有明确需求的直接开发（应使用 /blade-spec）或简单问答（应使用 /blade-doc）。
---

# Blade Storm — 协作式头脑风暴

好的想法需要好的对话来打磨。一次只问一个问题，一步步把模糊的念头变成清晰的设计蓝图。

## 核心理念

直接动手写代码，往往做出来的东西不是真正想要的。Blade Storm 在动手之前插入一段高质量的对话：

- **发散阶段**：通过提问挖掘需求全貌，避免遗漏关键场景
- **收敛阶段**：对比多种方案权衡取舍，找到最优解
- **验证阶段**：分段呈现设计，逐块确认，确保理解一致

最终产出经过人机共同验证的设计文档，可直接衔接 `/blade-spec` 进入开发。

## 铁律

- **一次一问**：每条消息只提一个问题，不用信息轰炸让人思考停滞
- **选择优于填空**：能给选项就给选项，降低用户的认知负担
- **YAGNI 原则**：设计中不放任何"以后可能用到"的东西，只保留当下确定需要的
- **方案先行**：在确定设计细节之前，先给出 2-3 种不同思路供对比
- **分段确认**：设计文档不一次性抛出，而是分 200-300 字的段落逐段确认
- **随时回溯**：用户任何时候说"不对"或"等等"，立刻停下来重新理清

## 使用方式

```
/blade-storm <想法描述>           # 启动新一轮头脑风暴
/blade-storm                     # 无参数，直接开始对话
```

**示例：**

```
/blade-storm 我想给系统加一个消息通知中心
/blade-storm 数据导出功能要不要做成异步的
/blade-storm 前端表单校验逻辑太散了，想统一管理
```

---

## 工作流

```
想法输入 → [理解上下文] → [逐步提问] → [方案探索] → [渐进式设计] → [文档输出] → 衔接开发
```

### 阶段一：理解上下文

在开口问第一个问题之前，先了解项目现状。

**执行步骤：**

1. **扫描项目状态**：
   - 读取 CLAUDE.md 了解项目架构和规范（如有）
   - 浏览与用户想法相关的现有模块、数据结构、路由
   - 检查近期 git 提交，了解团队当前的工作重心
   - 检查是否已有类似功能或半成品

2. **初步理解**：
   - 在心里勾勒用户想法的轮廓
   - 识别可能的技术约束和依赖
   - 标记需要向用户确认的疑点

3. **破冰回应**：
   - 用 1-2 句话复述对用户想法的初步理解
   - 如果扫描到了相关的现有代码或功能，简要提及
   - 抛出第一个问题，进入提问循环

### 阶段二：逐步提问

通过一系列精心设计的问题，逐步勾勒出需求的完整画像。

**提问策略：**

```
核心目标 → 用户角色 → 关键场景 → 边界约束 → 成功标准
```

1. **核心目标**（这东西解决什么问题）
   - "这个功能主要是给谁用的？"
   - "目前没有这个功能，大家是怎么绕过去的？"

2. **用户角色**（谁会用，怎么触发）
   - "使用这个功能的人是 (A) 管理员 (B) 普通用户 (C) 两者都有？"
   - "通常在什么场景下会触发这个操作？"

3. **关键场景**（正常流程和异常流程）
   - "最典型的使用流程是什么样的？"
   - "如果中途失败了，用户期望看到什么？"

4. **边界约束**（性能、安全、兼容性）
   - "数据量大概是什么级别？(A) 几百条 (B) 几万条 (C) 百万级以上"
   - "有没有必须兼容的旧接口或数据格式？"

5. **成功标准**（怎么算做好了）
   - "做完之后，怎么验证它是对的？"
   - "有没有可以参考的产品或竞品？"

**提问原则：**

- 每条消息只包含一个问题
- 优先使用选择题格式，如 `(A) xxx (B) xxx (C) xxx`
- 如果用户的回答引出新疑问，追问比跳到下一个话题更重要
- 不需要把所有问题都问完，信息足够就进入下一阶段
- 如果用户表现出"差不多了"/"你先说方案"的意愿，立即转入方案探索

### 阶段三：方案探索

当对需求有了足够理解后，提出 2-3 种实现思路进行对比。

**呈现格式：**

```
我想到了 N 种思路，先说我比较推荐的：

**方案一：[名称]** ⭐ 推荐
[2-3 句话说明核心思路]
- 优点：...
- 代价：...

**方案二：[名称]**
[2-3 句话说明核心思路]
- 优点：...
- 代价：...

**方案三：[名称]**（如有必要）
[2-3 句话说明核心思路]
- 优点：...
- 代价：...

我推荐方案一的原因是：[一段简洁的推理]

你倾向哪个方向？或者想调整组合一下？
```

**方案探索原则：**

- 推荐方案放在最前面，用 ⭐ 标记
- 每个方案要说清楚它在什么场景下最合适
- 方案之间要有实质差异，不是换个名字的同一个东西
- 明确说出推荐理由，让用户能做出有据可依的判断
- 用户可能想组合方案，保持灵活

### 阶段四：渐进式设计

用户选定方向后，开始输出详细设计。关键在于分段呈现、逐段确认。

**分段规则：**

- 每段 200-300 字，聚焦一个设计维度
- 每段末尾附一个确认问句
- 用户确认后才输出下一段
- 用户提出异议则当场调整，再继续

**设计维度（按需选取，不必每个都覆盖）：**

1. **整体架构**：新功能在系统中的位置，与现有模块的关系
2. **数据模型**：核心实体、字段设计、表关系
3. **接口设计**：API 端点、请求响应格式、权限要求
4. **核心流程**：主流程的时序或状态机
5. **前端交互**：页面布局、操作流程、组件划分
6. **异常处理**：错误场景的应对策略
7. **扩展考虑**：明确标注的未来可扩展点（仅在用户主动提及时）

**每段呈现格式：**

```
### [设计维度名称]

[200-300 字的设计描述]

---
这部分设计看起来合理吗？有什么需要调整的地方？
```

### 阶段五：文档输出

所有设计段落确认完毕后，汇总输出正式设计文档。

**执行步骤：**

1. 将所有已确认的设计段落整合为完整文档
2. 写入 `docs/plans/YYYY-MM-DD-<topic>-design.md`（日期取当天）
3. 使用 `/blade-commit` 提交文档

**文档结构：**

```markdown
# [功能名称] 设计方案

> 生成时间：YYYY-MM-DD
> 状态：已确认

## 背景与目标

[从提问阶段提炼的需求摘要]

## 方案选型

[选定方案及理由，简要列出被否决的方案]

## 详细设计

### [各设计维度]

[已确认的设计内容]

## 待决事项

[如有未确定的问题，列在此处]
```

4. 输出完成提示：

```
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  📝 设计文档已生成
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
路径: docs/plans/YYYY-MM-DD-<topic>-design.md

下一步建议:
  🚀 /blade-spec <需求描述>  →  进入规范驱动开发
  🎨 /blade-design           →  直接生成代码
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
```

---

## 对话节奏感知

整个过程中，密切关注用户的节奏信号：

| 用户信号 | 解读 | 行动 |
|---------|------|------|
| 回答详细，追问细节 | 希望深入探讨 | 继续提问，不急于收敛 |
| 回答简短，如"行"/"可以" | 希望加快节奏 | 减少提问，尽快进入方案 |
| "差不多了"/"你先说说" | 提问足够了 | 立即转入方案探索 |
| "等等"/"不对"/"往回说" | 前面有误解 | 回溯到出问题的地方 |
| "太复杂了"/"简单点" | 设计过度了 | 砍掉非必要部分 |
| "能不能快点" | 过程太长 | 合并剩余段落一次输出 |

---

## 与其他 Blade 技能的衔接

Blade Storm 处于整个开发工作流的最上游：

```
blade-storm（想法 → 设计）
    ↓
blade-spec（设计 → 任务拆解 → 自动开发）
    ↓
blade-design（代码生成）+ blade-commit（提交）
```

- 当设计方案已经足够明确，建议用户使用 `/blade-spec` 进入正式开发流程
- 当用户只需要快速生成代码而非完整设计，建议使用 `/blade-design`
- 不要在 blade-storm 阶段就开始写代码，这个阶段的产出是设计文档，不是代码