name: brainstorm description: “脑力激荡 - 需求发现 (AI编码增强)”

脑力激荡 - 需求发现 (AI编码增强)

指导AI在实施前通过协作需求发现，优化AI编码工作流：

任务优先（立即捕捉想法）
行动前询问（减少低价值问题）
研究优先以进行技术选择（避免让用户发明选项）
发散 → 收敛（扩展思维，然后锁定MVP）

何时使用

当用户描述开发任务时，从 /trellis:start 触发，特别是在：

需求不清晰或正在演变
有多个有效实施路径
权衡很重要（用户体验、可靠性、可维护性、成本、性能）
用户可能不知道最佳选项时

核心原则（不可协商）

任务优先（早期捕捉） 始终确保开始时存在任务，以便立即记录用户想法。
行动前询问 如果你可以从仓库代码、文档、配置、约定或快速研究中推导答案，先做这个。
每条消息一个问题 永远不要用问题列表淹没用户。问一个，更新PRD，重复。
偏好具体选项 对于偏好/决策问题，提出2-3个可行的、具体的方法，包括权衡。
技术选择研究优先 如果决策依赖于行业约定/类似工具/既定模式，先做研究，然后提出选项。
发散 → 收敛 在初步理解后，主动考虑未来演变、相关场景和失败/边缘情况，然后收敛到具有明确排除范围的MVP。
无元问题 不要问“我应该搜索吗？”或“你能粘贴代码以便我继续吗？” 如果需要信息：搜索/检查。如果受阻：问最小的阻碍问题。

步骤0：确保任务存在（始终）

在任何问答之前，确保任务存在。如果没有，立即创建一个。

使用从用户消息派生的临时工作标题。
标题不完美没关系——稍后在PRD中完善。

TASK_DIR=$(python3 ./.trellis/scripts/task.py create "brainstorm: <简短目标>" --slug <自动>)

立即用已知信息创建/种子 prd.md：

# brainstorm: <简短目标>

## 目标

<一段：什么 + 为什么>

## 我已经知道的信息

* <用户消息中的事实>
* <从仓库/文档中发现的事实>

## 假设（临时）

* <需要验证的假设>

## 开放问题

* <仅限阻碍/偏好问题；保持列表简短>

## 需求（演变中）

* <从已知开始>

## 验收标准（演变中）

* [ ] <可测试的标准>

## 完成定义（团队质量标准）

* 添加/更新测试（单元/集成，如适用）
* Lint / 类型检查 / CI 通过
* 如果行为改变，更新文档/笔记
* 如果风险高，考虑推出/回滚

## 排除范围（明确）

* <在此任务中不会做什么>

## 技术笔记

* <检查的文件、约束、链接、参考资料>
* <如适用，研究笔记摘要>

步骤1：自动上下文（在提问前执行此步骤）

在提问如“代码看起来像什么？”之前，自行收集上下文：

仓库检查清单

识别可能影响的模块/文件
定位现有模式（类似功能、约定、错误处理风格）
检查配置、脚本、现有命令定义
注意任何约束（运行时、依赖策略、构建工具）

文档检查清单

查找现有PRD/规范/模板
查找命令使用示例、README、ADR（如有）

将发现写入PRD：

添加到我已经知道的信息
添加约束/链接到技术笔记

步骤2：分类复杂性（仍然有用，不阻止任务创建）

复杂性	标准	行动
简单	单行修复、错别字、明显更改	跳过脑力激荡，直接实施
简单	目标明确，1-2个文件，范围定义清晰	问1个确认问题，然后实施
中等	多个文件，有些模糊性	轻度脑力激荡（2-3个高价值问题）
复杂	目标模糊、架构选择、多个方法	完整脑力激荡

注意：任务已从步骤0存在。分类仅影响脑力激荡深度。

步骤3：问题门控（仅问高价值问题）

在提问任何问题之前，运行以下门控：

门控A — 我能否在没有用户的情况下推导此问题？

如果答案可通过以下方式获取：

仓库检查（代码/配置）
文档/规范/约定
快速市场/开源研究

→ 不要问。 获取它，总结，更新PRD。

门控B — 这是一个元/懒惰问题吗？

示例：

“我应该搜索吗？”
“你能粘贴代码以便我继续吗？”
“代码看起来像什么？”（当仓库可用时）

→ 不要问。 采取行动。

门控C — 这是什么类型的问题？

阻碍型：没有用户输入无法继续
偏好型：多个有效选择，取决于产品/用户体验/风险偏好
可推导型：应通过检查/研究回答

→ 仅问阻碍型或偏好型。

步骤4：研究优先模式（技术选择必选）

触发条件（任何 → 研究优先）

任务涉及选择方法、库、协议、框架、模板系统、插件机制或CLI用户体验约定
用户要求“最佳实践”、“他人如何做”、“推荐”
用户无法合理列举选项

研究步骤

识别2-4个可比较的工具/模式
总结常见约定及其存在原因
将约定映射到我们仓库的约束
为我们项目生成2-3个可行方法

研究输出格式（PRD）

在PRD中添加部分（在技术笔记内或单独）：

## 研究笔记

### 类似工具的做法

* ...
* ...

### 来自我们仓库/项目的约束

* ...

### 这里的可行方法

**方法A: <名称>**（推荐）

* 工作原理：
* 优点：
* 缺点：

**方法B: <名称>**

* 工作原理：
* 优点：
* 缺点：

**方法C: <名称>**（可选）

* ...

然后问一个偏好问题：

“你更喜欢哪种方法：A / B / C（或其他）？”

步骤5：扩展扫掠（发散）——在初步理解后必做

在你能总结目标后，在收敛前主动扩展思维。

扩展类别（每类别保持1-2点）

未来演变
- 这个功能可能在1-3个月内变成什么？
- 现在值得保留哪些扩展点？
相关场景
- 哪些相邻命令/流程应与此保持一致？
- 是否有对等期望（创建vs更新、导入vs导出等）？
失败与边缘情况
- 冲突、离线/网络故障、重试、幂等性、兼容性、回滚
- 输入验证、安全边界、权限检查

扩展消息模板（给用户）

我理解你想实施：<当前目标>。

在设计前，让我快速发散考虑三个类别（以避免以后重做）：

1. 未来演变：<1-2点>
2. 相关场景：<1-2点>
3. 失败/边缘情况：<1-2点>

对于这个MVP，你想包括哪些（或无）？

1. 仅当前需求（最小可行）
2. 添加<X>（为未来扩展保留）
3. 添加<Y>（提高稳健性/一致性）
4. 其他：描述你的偏好

然后更新PRD：

包含在MVP中 → 需求
排除 → 排除范围

步骤6：问答循环（收敛）

规则

每条消息一个问题
可能时偏好多项选择
每个用户回答后：
- 立即更新PRD
- 将已回答项从开放问题移到需求
- 用可测试复选框更新验收标准
- 澄清排除范围

问题优先级（推荐）

MVP范围边界（包括/排除什么）
偏好决策（在提出具体选项后）
失败/边缘行为（仅对MVP关键路径）
成功指标和验收标准（什么证明它有效）

偏好问题格式（多项选择）

对于<主题>，你偏好哪种方法？

1. **选项A** — <含义 + 权衡>
2. **选项B** — <含义 + 权衡>
3. **选项C** — <含义 + 权衡>
4. **其他** — 描述你的偏好

步骤7：提出方法 + 记录决策（复杂任务）

在需求足够清晰后，提出2-3个方法（如果未通过研究优先完成）：

基于当前信息，这里有2-3个可行方法：

**方法A: <名称>**（推荐）

* 如何：
* 优点：
* 缺点：

**方法B: <名称>**

* 如何：
* 优点：
* 缺点：

你更喜欢哪个方向？

在PRD中记录结果为ADR-lite部分：

## 决策（ADR-lite）

**背景**：为什么需要此决策
**决策**：选择了哪个方法
**后果**：权衡、风险、潜在未来改进

步骤8：最终确认 + 实施计划

当开放问题解决后，用结构化总结确认完整需求：

最终确认格式

以下是我对完整需求的理解：

**目标**：<一句话>

**需求**：

* ...
* ...

**验收标准**：

* [ ] ...
* [ ] ...

**完成定义**：

* ...

**排除范围**：

* ...

**技术方法**：
<简要摘要 + 关键决策>

**实施计划（小PR）**：

* PR1: <脚手架 + 测试 + 最小基础>
* PR2: <核心行为>
* PR3: <边缘情况 + 文档 + 清理>

这看起来正确吗？如果是，我将开始实施。

PRD目标结构（最终）

prd.md 应收敛到：

# <任务标题>

## 目标

<为什么 + 什么>

## 需求

* ...

## 验收标准

* [ ] ...

## 完成定义

* ...

## 技术方法

<关键设计 + 决策>

## 决策（ADR-lite）

背景 / 决策 / 后果

## 排除范围

* ...

## 技术笔记

<约束、参考资料、文件、研究笔记>

反模式（硬避免）

询问用户可以从仓库推导的代码/上下文
在提出具体选项前让用户选择方法
关于是否研究的元问题
仅关注初始请求而不考虑演变/边缘情况
让脑力激荡漂移而不更新PRD

与启动工作流集成

高层流程：

用户描述任务
↓
步骤0：确保任务存在（如缺失则创建）
↓
步骤1：自动上下文（检查仓库/文档，如需要则研究）
↓
步骤2：分类复杂性
↓
步骤4（如触发）：研究优先 → 提出选项
↓
步骤5：扩展扫掠（发散）
↓
步骤6：问答循环（收敛；每轮更新PRD）
↓
步骤8：最终确认 + 小PR计划
↓
实施

命令	何时使用
`/trellis:start`	触发脑力激荡的入口点
`/trellis:finish-work`	实施完成后
`/trellis:update-spec`	如果在工作期间出现新模式

脑力激荡需求发现技能Skill brainstorm