194 lines
5.5 KiB
Markdown
194 lines
5.5 KiB
Markdown
---
|
||
name: brainstorming
|
||
description: 在任何创造性工作前执行此步骤——包括创建功能、构建组件、添加功能或修改行为。在实施前探究用户意图、需求与设计方案。通过自然协作对话，将创意转化为完整的设计方案与规格说明。当用户提及"新功能"、"构建"、"创建组件"、"添加功能"、"实现"或开始任何开发工作时触发本技能。本技能会自动调用 project-context 技能获取用户画像和流程路径推荐。
|
||
license: MIT
|
||
metadata:
|
||
version: "3.0.0"
|
||
---
|
||
|
||
# 头脑风暴技能
|
||
|
||
本技能是任何创造性工作前的必经步骤，通过协作对话将创意转化为完整的设计规格说明。
|
||
|
||
---
|
||
|
||
## 核心原则
|
||
|
||
### 设计优先
|
||
|
||
在用户批准设计文档前，请勿：
|
||
|
||
- 调用任何实施技能
|
||
- 编写任何代码
|
||
- 搭建项目框架
|
||
- 采取任何实施行动
|
||
|
||
### 会话状态管理
|
||
|
||
使用统一的会话状态文件跟踪进度：
|
||
|
||
- **路径**：`design/session-state.md`
|
||
- **模板**：`references/session-state-template.md`
|
||
|
||
**操作时机**：
|
||
|
||
- 技能激活时 → **创建状态文件**，如果状态文件存在，则将旧文件重命名为：session-state-YYYYMMDDHHMMSS.md
|
||
- 获得用户确认后 → **更新状态文件**
|
||
- 每轮对话开始时 → 读取状态文件恢复上下文
|
||
- **每个阶段完成后 → 更新状态文件**
|
||
|
||
### 终止条件
|
||
|
||
本技能的唯一终止方式是调用 `writing-plan` 技能，并传递规格文档路径。
|
||
|
||
---
|
||
|
||
## 工作流程
|
||
|
||
### 阶段 1：探索背景
|
||
|
||
**目标**：了解当前项目状态，评估需求范围。
|
||
|
||
**执行动作**：
|
||
|
||
1. 调用 `project-context` 技能获取用户画像
|
||
2. 读取项目上下文（如有）：`design/context/project-context.md`
|
||
3. 检查项目文件结构
|
||
4. 评估需求是否涉及多个独立子系统
|
||
5. **主动更新用户画像**（如果识别到新的偏好或技术背景）
|
||
|
||
**范围检查**：
|
||
|
||
- 若请求涉及多个独立子系统，协助用户分解为子项目
|
||
- 每个子项目独立进行头脑风暴
|
||
|
||
**完成标准**：已了解项目技术栈和现有结构，已确认需求范围，用户画像已更新（如有变化）
|
||
|
||
---
|
||
|
||
### 阶段 2：确认需求
|
||
|
||
**目标**：逐条理解目标、约束条件和成功标准。
|
||
|
||
**执行规则**：
|
||
|
||
- 每条消息只提一个问题
|
||
- 优先使用选择题形式
|
||
|
||
**核心问题清单**（按顺序询问）：
|
||
|
||
| 序号 | 问题类型 | 示例问题 |
|
||
| ---- | -------- | -------------------------------- |
|
||
| 1 | 目标定位 | "这个功能的主要用户是谁？" |
|
||
| 2 | 约束条件 | "有没有时间或技术栈的限制？" |
|
||
| 3 | 成功标准 | "如何判断这个功能是否成功交付？" |
|
||
| 4 | 边界情况 | "有没有需要特别处理的边界情况？" |
|
||
|
||
**完成标准**：目标定位明确、约束条件清晰、成功标准可验证
|
||
|
||
---
|
||
|
||
### 阶段 3：方案选择
|
||
|
||
**目标**：提供 2-3 种不同方案及其权衡分析。
|
||
|
||
**执行动作**：
|
||
|
||
1. 提出 2-3 种不同方案
|
||
2. 说明每种方案的优缺点
|
||
3. 给出推荐方案及理由
|
||
|
||
**完成标准**：用户已选择一个方案
|
||
|
||
> 参考：`references/tech-selection-guide.md`
|
||
|
||
---
|
||
|
||
### 阶段 4：设计文档
|
||
|
||
**目标**：将验证通过的设计写入规格文档。
|
||
|
||
**执行动作**：
|
||
|
||
1. 创建规格文档：`design/specs/YYYY-MM-DD-<topic>-design.md`
|
||
2. 包含所有已确认的内容
|
||
3. 确保无 TODO、TBD 或占位符
|
||
|
||
**文档结构**：
|
||
|
||
| 章节 | 内容要求 |
|
||
| -------- | -------------------- |
|
||
| 概述 | 功能目标、背景上下文 |
|
||
| 目标定位 | 主要用户和使用场景 |
|
||
| 约束条件 | 技术、时间、资源限制 |
|
||
| 成功标准 | 可验证的交付标准 |
|
||
| 架构设计 | 系统结构和组件划分 |
|
||
| 数据流 | 数据如何流转 |
|
||
| 错误处理 | 异常情况处理策略 |
|
||
| 测试策略 | 如何验证功能正确性 |
|
||
|
||
**完成标准**：文档已写入指定路径，无占位符内容
|
||
|
||
> 参考：`references/spec-template.md`
|
||
|
||
---
|
||
|
||
### 阶段 5：交接
|
||
|
||
**目标**：获得用户批准，调用 writing-plan 技能。
|
||
|
||
**执行动作**：
|
||
|
||
1. 呈现规格文档路径给用户
|
||
2. 请用户审阅并确认
|
||
3. 若用户批准，调用 writing-plan 技能
|
||
|
||
**标准话术**：
|
||
|
||
> "规格文档已编写并提交至 `<path>`。请审阅，确认后我将开始制定实施计划。"
|
||
|
||
**调用格式**：
|
||
|
||
```
|
||
调用 writing-plan 技能，规格文档路径：<path>
|
||
```
|
||
|
||
**终止**：此阶段完成后，本技能结束。
|
||
|
||
---
|
||
|
||
## 参考指南
|
||
|
||
| 参考文档 | 用途 |
|
||
| ---------------------------------------- | ---------------- |
|
||
| `references/session-state-template.md` | 会话状态文件模板 |
|
||
| `references/spec-template.md` | 规格文档模板 |
|
||
| `references/tech-selection-guide.md` | 技术选型指导 |
|
||
| `references/risk-assessment-template.md` | 风险评估模板 |
|
||
|
||
---
|
||
|
||
## 常见问题
|
||
|
||
### 用户坚持跳过设计直接实施？
|
||
|
||
回复：
|
||
|
||
> "我理解您希望快速推进。设计文档可以很简短，但需要记录并获得您的批准，这能确保我们对目标达成共识，避免后续返工。"
|
||
|
||
### 项目范围过大怎么办？
|
||
|
||
处理方式：
|
||
|
||
1. 标记为多子系统项目
|
||
2. 协助用户分解为独立子项目
|
||
3. 对第一个子项目开始头脑风暴
|
||
4. 每个子项目独立进行规格→规划→实施循环
|
||
|
||
### 对话中断后如何恢复？
|
||
|
||
处理方式：
|
||
|
||
1. 读取会话状态文件 `design/session-state.md`
|
||
2. 根据"下一步"继续执行
|