brainstorming

name	brainstorming
description	创建功能、构建组件、添加特性或修改行为前必须使用。探索用户意图、需求和设计，获得批准后才能写代码。触发词：做功能、加特性、构建、新项目、我想做、let's build、implement、create feature。
agent_created	true

头脑风暴 → 设计文档

在动手写代码之前，通过结构化对话把想法变成完整设计。

硬门禁（HARD GATE）

在设计获得用户批准之前，禁止调用任何实现技能、写任何代码、搭建任何项目框架。

每个项目都要过这关——Todo 列表、工具函数、配置修改，全都不例外。简单的项目可以有简短的设计，但你必须呈现设计并获取批准。

反模式："这个太简单不需要设计"

每个项目都要走这个流程。"简单"项目恰恰是未经检验的假设造成最多浪费的地方。设计可以短（真正简单的项目只需几句话），但必须呈现并获得批准。

检查清单（按顺序完成）

1. 探索项目上下文 — 检查文件、文档、最近的提交记录
2. 提出澄清性问题 — 一次只问一个，理解目的、约束、成功标准
3. 提出 2-3 个方案 — 带权衡分析和你推荐的方案
4. 呈现设计方案 — 按复杂度分节展示，每节获取用户批准
5. 编写设计文档 — 保存到 docs/plans/YYYY-MM-DD-<主题>-design.md 并提交
6. 规格自查 — 快速检查占位符、矛盾、歧义、范围
7. 用户审查 — 请用户审查规格文档再继续
8. 移交实现 — 调用 writing-plans 技能创建实现计划

提问规则

• 每条消息只问一个问题
• 优先使用选择题，开放式也行
• 理解：目的、约束、成功标准、明确不做什么

方案探讨

• 提出 2-3 个不同方案，每个带权衡分析
• 对话式呈现，先说你推荐的，并解释原因

设计呈现

• 确认理解后，呈现设计
• 按复杂度调整每节长度
• 每节问"这看起来对吗？"
• 覆盖：架构、组件、数据流、错误处理、测试策略

关键原则

• 一次一个问题，不要轰炸
• 选择题优先
• YAGNI 无情——移除所有设计中不必要的功能
• 探索替代方案——确定前至少提 2-3 个
• 渐进式验证——呈现设计，获批准，再前进
• 灵活——哪里不对就回去澄清

设计文档

# [功能名称] 设计文档

**目标:** [一句话描述要构建什么]
**架构:** [2-3 句关于方案]
**技术栈:** [关键技术/库]
**文件结构:** [新建/修改的文件，每个文件的职责]
**数据流:** [数据如何流转]
**错误处理:** [错误处理策略]
**测试策略:** [如何测试]

撰写设计文档后

1. 占位符扫描 — 有 "TBD"、"TODO"、不完整的部分吗？修复。
2. 内部一致性 — 各部分有矛盾吗？架构和功能描述一致吗？
3. 范围检查 — 足够聚焦吗？还是需要再分解？
4. 歧义检查 — 有需求能有两种解读吗？选定一种并明确。

然后请用户审查，等待批准后再调 writing-plans。