名称: 头脑风暴 描述: “在实施前进行设计。在任何创造性或建设性工作（功能、架构、行为变更）之前使用，将模糊的想法转化为经过验证的设计。”
通过结构化对话，将原始想法转化为清晰、经过验证的设计，在任何实施开始之前。
头脑风暴前
- 检查是否需要设计：变更是否足够复杂，需要设计阶段，还是解决方案已经明确？
- 回顾现有成果：检查
.context/DECISIONS.md中相关的过往决策；不要重新讨论已确定的决策。 - 识别现有内容：在提问前阅读相关代码和文档；不要询问代码库已经解答的问题。
何时使用
- 实施新功能之前
- 进行架构变更之前
- 进行重大行为修改之前
- 当想法模糊需要塑形时
何时不使用
- 有明确解决方案的缺陷修复
- 日常维护任务
- 当需求已经明确定义时
- 小型、独立的变更（直接执行即可）
- 当用户明确希望直接开始编码时
使用示例
/头脑风暴
/头脑风暴 (为API设计新的缓存层)
/头脑风暴 (我们应该拆分单体架构吗？)
操作模式
设计促进者，而非构建者。
- 头脑风暴期间不进行实施
- 不推测功能
- 不进行无声假设
- 不跳过步骤
放慢速度，确保正确无误。
流程
1. 理解当前背景
在提问之前：
- 审查项目状态：文件、文档、过往决策
- 检查
.context/DECISIONS.md中相关的过往决策 - 识别现有内容与提议内容
- 注意隐含约束
此时不要开始设计。
2. 澄清想法
目标：达成共同清晰的理解，而非追求速度。
规则：
- 每次消息只问一个问题
- 可能时优先使用多项选择题
- 将复杂主题拆分为多个问题
关注点：
- 目的：为什么需要这个？
- 用户：谁受益？
- 约束：有哪些限制？
- 成功标准：如何知道它有效？
- 非目标：明确排除哪些内容？
3. 非功能性需求
明确澄清或提出以下假设：
- 性能预期
- 规模（用户、数据、流量）
- 安全/隐私约束
- 可靠性需求
- 维护预期
如果用户不确定，提出合理的默认值并标记为假设。
4. 理解锁定（关卡）
在提出任何设计之前，暂停并提供：
理解摘要（5-7个要点）：
- 要构建什么
- 为什么存在
- 为谁而建
- 关键约束
- 明确的非目标
假设：列出所有明确的假设。
开放问题：列出未解决的事项。
然后询问：
“这准确反映了您的意图吗？在我们进入设计之前，请确认或更正。”
在确认之前不要继续。
5. 探索设计方案
一旦理解得到确认：
- 提出2-3个可行的方案
- 首先提出您的推荐方案
- 解释权衡：复杂性、可扩展性、风险、维护性
- 严格应用YAGNI（你不会需要它）原则
6. 呈现设计
分解为易于理解的部分。每部分后询问：
“到目前为止看起来正确吗？”
根据相关情况涵盖：
- 架构
- 组件
- 数据流
- 错误处理
- 边缘情况
- 测试策略
7. 决策日志
在整个过程中维护运行日志：
| 决策 | 备选方案 | 理由 |
|---|---|---|
| … | … | … |
设计之后
持久化到上下文
一旦验证通过，持久化输出：
# 记录关键决策
ctx add decision "..." --context "..." --rationale "..."
实施交接
仅在文档完成后询问：
“准备好开始实施了吗？”
如果回答是：
- 创建明确的实施计划
- 分解为增量步骤
- 一次执行一个步骤
优秀示例
理解摘要：
- 为
ctx agent钩子构建冷却机制- 防止每次工具使用时重复注入上下文
- 针对在PreToolUse钩子中运行ctx的Claude Code用户
- 必须会话隔离（两个会话不共享状态）
- 非目标：每个工具的粒度（冷却是全局的）
假设：10分钟默认冷却时间是合理的。
开放问题：无剩余。
这准确反映了您的意图吗？
不良示例
- 在询问功能用途之前就跳到架构图
- 一次消息中提出5个问题（一次只问一个）
- 未经过理解锁定步骤就提出设计
- “让我快速实现这个”（头脑风暴期间不实施）
质量检查清单
仅在以下情况时退出头脑风暴模式：
- [ ] 用户确认了理解锁定
- [ ] 至少一个设计方案被接受
- [ ] 主要假设已明确记录
- [ ] 关键风险已确认
- [ ] 决策日志已完成
- [ ] 决策已持久化到
.context/DECISIONS.md
如果任何标准未满足，继续完善。
原则
- 逐步思考，在提出任何方案之前——在跳转到解决方案之前，先推理问题空间
- 一次只问一个问题
- 假设必须明确
- 在承诺前探索备选方案
- 增量验证
- 清晰优于巧妙
- 愿意回溯
- 严格应用YAGNI