Brainstorm 用于在实施前引导 AI 与用户协作完成需求发现，面向 AI 编程工作流优化：任务优先、先行动后提问、技术选择先调研、先发散再收敛。
适用场景：用户描述开发任务且需求不清或仍在变化、存在多种可行实现路径、需要权衡取舍（体验、可靠性、可维护性、成本、性能），或用户未必知道最佳选项时使用；通常由 $start 触发。
核心原则：尽早确保任务存在以记录想法；能从仓库代码、文档、配置、约定或快速调研中得到答案的，先自行获取，不向用户提问；每条消息只问一个问题；偏好类问题给出 2–3 个具体可行方案及取舍；技术选择先调研行业惯例与同类工具再提方案；先发散考虑演进、关联场景与失败/边界情况，再收敛到 MVP 并明确排除项；不提“要不要我搜索”这类元问题。
流程：Step 0 始终先确保任务存在，用 python3 ./.trellis/scripts/task.py create "brainstorm: <short goal>" --slug <auto> 创建任务目录并立即写入 prd.md 初稿（含目标、已知事实、假设、开放问题、演进中的需求与验收标准、完成定义、范围外、技术笔记）。Step 1 先自动收集上下文：排查可能受影响的模块与既有模式、配置与脚本、约束，以及已有 PRD/规范/文档与使用示例，并把发现写入 PRD。Step 2 按复杂度分级（Trivial 直接实现、Simple 问一个确认问题、Moderate 轻度头脑风暴、Complex 完整头脑风暴），任务已在 Step 0 创建，分级只影响深度。Step 3 提问前过三道门：能否自行推导（能则不问）、是否属于元/偷懒问题（不行动而问）、问题类型（仅问阻塞型或偏好型）。Step 4 涉及方案、库、协议、框架、模板系统、插件机制或 CLI 约定等选择时进入调研优先模式，梳理 2–4 个同类工具惯例、映射本仓库约束、给出 2–3 个可行方案并在 PRD 增加 Research Notes，再问偏好。Step 5 做发散扫描（未来演进、关联场景、失败与边界），让用户选择最小可行或加入哪些项，并更新 PRD 的需求与范围外。Step 6 进入问答收敛循环，逐条更新 PRD 与验收标准。Step 7 复杂任务提出 2–3 个方案并记录 ADR-lite（上下文/决策/后果）。Step 8 最终确认结构化摘要与实施计划（拆成小 PR），用户确认后进入 Task Workflow 第 2 阶段。复杂任务可创建子任务：python3 ./.trellis/scripts/task.py create "Child task 1" --slug child1 --parent "$TASK_DIR"，或用 python3 ./.trellis/scripts/task.py add-subtask "$TASK_DIR" "$CHILD_DIR" 关联已有任务。
限制与注意：硬性避免的坏习惯包括向用户索要本可从仓库推导的代码或上下文、未给具体选项就让用户选方案、就是否调研提问、只盯初始请求而不考虑演进与边界、以及发散后不更新 PRD。相关资料未提供该技能的收费、价格、平台支持范围与效果数据。