Trellis Brainstorm 是做什么的？
非协商性规划契约
请求构建、实现、修复、重构或“继续推进”并不等同于允许离开规划阶段。任务创建同意也不是实现批准。
对于每一个非琐碎的任务，用户必须在初始请求之后、实现开始之前至少响应一次。如果不需要澄清，该响应必须批准下面描述的最终规划摘要。
在任何用户拥有的产品、范围、UX、兼容性、风险或验收决策尚未解决时，结束当前轮次时只能提出一个最高价值的问题。不要编辑产品代码、调度的实现，或运行 task.py start。
非协商性证据规则
如果一个问题可以通过探索代码库来回答，那么就去探索代码库。
这是强制性的。在向用户提问之前，首先检查答案是否已经在代码、测试、配置、文档、现有规范或任务历史中可用。
不要要求用户确认仓库可以回答的事实。只询问产品意图、偏好、范围、风险承受度、验收行为，或在检查后仍然模糊不清的决策。
仓库证据确定了当前行为和技术约束。用户的预期行为、功能范围边界和UX偏好是仓库证据永远无法单独回答的，即使存在现有模式；现有模式是选项和推荐证据，而不是决策。
在阶段 1 规划期间使用此技能，将用户的请求转化为清晰的需求和规划工件。
前置条件
仅在任务创建同意已被给予且用户准备好进入 Trellis 规划后使用此技能。
如果尚不存在任务，请创建一个：
TASK_DIR=$(python3 ./.trellis/scripts/task.py create "<简短的任务标题>" --description "<一行摘要>" --slug <slug>)
使用用户请求中的简洁标题。标题和 --description 都必须非空——create 会拒绝空值，并且任一记录为空都会在归档时被拒绝。使用不带日期前缀的 slug。task.py create 会自动添加 MM-DD- 目录前缀。
task.py create 会创建默认的 prd.md。在提出后续问题之前，先用当前的理解更新该文件。
规划流程
- 将用户的请求和初始已知事实捕获到
prd.md中。 - 在提问之前检查可用证据：
- 代码、测试、fixtures 和配置
- README 文件、文档、现有规范和领域说明
- 相关的 Trellis 任务、研究文件和会话历史（如果存在）
- 将发现的内容分为：
- 已确认的事实
- 仍然需要从用户处获取的产品意图
- 仍然需要从用户处获取的范围或风险决策
- 可能超出范围的项目
- 如果存在用户拥有的决策，提出单一最高价值的问题，包含您的建议和权衡，然后停止。不要在同一轮次中执行实现工作。
- 在每次用户回答后，更新
prd.md，重新计算决策清单，并从步骤 2 开始重复。 - 当没有用户拥有的决策时，为复杂任务创建或更新
design.md和implement.md。 - 运行需求收敛门，然后运行 PRD 收敛遍历。
- 呈现最终的规划摘要并停止。不要在同一轮次中运行
task.py start或编辑产品代码。 - 只有后续一条明确批准最新规划摘要的用户消息才授权执行
task.py start和实现。如果工件在批准后有实质性变更，则重复最终审查。
不要发明项目特定的产品/规范层级。如果仓库已有产品、领域或规范文档，请使用它们。如果没有，则使用现有证据进行。
问题规则
每条消息只问一个问题。
每个问题必须包含：
- 需要的决策
- 答案为何重要
- 您推荐的答案
- 如果用户做出不同选择的权衡
不要问过程性问题，例如是否搜索、检查文件或继续头脑风暴。直接进行证据工作。只有当剩余问题是产品决策、偏好、范围边界或风险承受度选择时，才向用户提问。
推荐不是默认选择。永远不要仅仅因为用户要求实现，就代表用户选择推荐的决策。
当请求和仓库证据已经解决了所有决策时，不要制造澄清问题。在这种情况下，直接进入最终规划摘要，该摘要仍然需要后续的明确批准。
最终审查是一个必需的阶段转换门，而非被禁止的过程性问题。任务创建同意、初始实现请求以及在最新最终摘要之前给出的批准不能满足此门的要求。
思考框架：第一性原理分析
当需求模糊、解决方案感觉过于复杂，或者你即将因为“大家都这么做”而增加复杂性时——分解到基本事实，然后向上推理。
第 1 步：重述问题
剥离实现细节，归结为一句话。
差：“我们需要为用户资料端点添加 Redis 缓存” 好：“用户资料数据加载时间过长”
第 2 步：列出基本事实
什么是绝对正确的（不是意见或惯例）？
| 类别 | 示例 |
|---|---|
| 物理约束 | 网络延迟 ≥ 0，磁盘 I/O 有限制 |
| 业务规则 | “用户必须能看到自己的数据” |
| 技术不变量 | “数据必须保持一致” |
| 用户需求 | “用户希望在 Y 秒内得到 X” |
第 3 步：挑战假设
针对当前计划的每个组成部分：
- 事实还是惯例？ “我们总是用 REST”——为什么？
- 如果移除这个呢？ 如果什么都没有损坏，那它就是不必要的。
- 是在解决实际问题还是症状？ 追踪因果链。
- 谁从这种复杂性中受益？ 如果是“没有人”，就简化。
第 4 步：从事实出发构建
- 从满足所有事实的最小可行机制开始
- 仅当特定事实要求时才增加复杂性
- 每次增加都必须回答：“哪个事实要求这个？”
第 5 步：验证
- 解决方案是否解决了原始问题？
- 哪些假设需要验证？
- 测试这个的最简单的实验是什么？
需求收敛门
在最终审查之前，验证以下所有内容：
- 用户结果和产品价值已明确
- 范围内和范围外的行为已明确
- 验收标准描述了可观察到的结果
- 用户拥有的产品、范围、UX、兼容性和风险决策已解决
- 阻碍性的开放问题为空
- 技术未知项已研究或明确推迟，且不影响 MVP 行为
轻量级任务可以省略 design.md 和 implement.md；但不能跳过证据检查、需求收敛、最终审查或新的实现批准。
最终规划摘要必须展示目标、范围内、范围外、验收标准、关键决策、相关风险或推迟项，以及工件状态。
工件规则
prd.md 记录需求和验收：
- 目标和用户价值
- 已确认的事实
- 需求
- 验收标准
- 范围外
- 仍阻碍规划的开放问题
design.md 记录复杂任务的技术设计：
- 架构和边界
- 数据流和契约
- 兼容性和迁移说明
- 重要的权衡
- 运营或回滚注意事项
implement.md 记录复杂任务的执行计划：
- 有序的实现检查清单
- 验证命令
- 高风险文件或回滚点
- 在
task.py start之前的后续检查
轻量级任务可能只有 prd.md。复杂任务在 task.py start 之前必须有 prd.md、design.md 和 implement.md。
implement.md 不能替代 implement.jsonl。在子代理调度工作流中，implement.jsonl 和 check.jsonl 各自必须在 task.py start 之前包含至少一个真实的规范/研究条目；空的清单或仅包含遗留的 _example 占位符行的清单不计入。内联工作流跳过这个 JSONL 门，因为阶段 2 通过 trellis-before-dev 加载上下文。
PRD 收敛遍历
在宣布规划就绪或运行 task.py start 之前，根据上述工件规则中描述的最终结构重写 prd.md。这不是可选的清理工作；这是最终的规划门。
遍历必须无损：
- 将重复的事实折叠成一个权威部分。
- 将临时的头脑风暴部分（例如“我已经知道什么”、“假设”和已解决的“开放问题”）折叠到目标、背景、需求、技术说明或验收标准中。
- 删除已解决的开放问题，而不是留下空部分或已回答的部分。
- 当描述相同工作时，合并并行的错误列表和需求列表；将每个缺陷的严重性、证据和文件:行锚点保留在所属需求中。
- 保留每个文件:行锚点、决策、约束、需求 ID 和验收标准映射。
- 在仍有阻碍性开放问题的情况下，不要进入最终审查。
遍历之后，从头到尾阅读 prd.md，并确认没有事实在不同部分重复，除非该重复增加了新信息。
质量标准
在宣布规划就绪之前：
prd.md包含可测试的验收标准。prd.md已通过 PRD 收敛遍历：没有未解决的临时头脑风暴部分，没有跨部分的重复事实，没有丢失锚点、决策或验收映射。- 仓库可回答的问题已通过检查得到回答。
- 阻碍性的开放问题为空。
- 复杂任务有
design.md和implement.md。 - 子代理调度任务在
implement.jsonl和check.jsonl中都有真实的精心挑选的条目；仅含种子数据的清单不算就绪。 - 最新的最终规划摘要已呈现给用户。
- 在后续消息中，用户已明确批准该摘要用于实现。
不要仅仅因为用户最初请求了实现就开始实现。