brainstorm

头脑风暴

直接调用时，先使用 shared/references/model-preview.md 选择分支。协调工作和确定性命令在调用权限范围内执行。实际的工作分支使用一个已批准的路由快照。嵌套调用复用该快照，不再选择路由或添加工作者。

判断是否构建以及要探索哪个方向。坚持先讲为什么，再讲怎么做：先明确问题，再选择机制。根据用户需求和项目情况，拓展解决方案空间，考虑其他方案。不要编写生产代码或实现任务。

1. 理解问题

结合现有上下文，检查相关代码、文档和先前决策。只询问研究无法回答的问题：影响对象是谁、目前哪里出了问题、问题为何重要，以及哪些约束会影响决策。除非有新证据，否则不要重新讨论已确定的决策。

2. 比较可行的方向

比较当前方案、最小的有效改动，以及存在时实质上不同的选项。说明预期结果、成本和主要风险。关于项目的说法必须引用本次运行中检查过的文件；对假设和未经核实的外部说法加以标注。

生成创意时，阅读 references/idea-basis-contract.md：每个创意都需要有来源或明确的推理依据。用户无法评估某个领域时，阅读 references/blindspot-pass.md。其领域关卡必须先于一批有依据的决策。

只有在用户明确要求评议小组时才使用 models-consensus。该技能负责单独的小组审批、路由、分派和小组产物。在此处使用其报告，并提供中立的问题陈述。不要为了常规选项组建评议小组。

3. 选择方向

推荐一个选项，并解释关键权衡。请用户确认或更改方向。解决实质性异议；不要求固定数量的选项或轮次。

4. 给出结论

给出 BUILD、DEFER、REDUCE SCOPE 或 REJECT，并说明原因、拟定范围、排除项、未解决的决策和证据。对于 DEFER，指出应在什么事件发生时重新讨论。没有衡量依据时，避免给出数值置信度。

对于 BUILD 或 REDUCE SCOPE，将已达成一致的方向交给 interview-me，由其在进入 to-prd 之前确定需求。只有在用户请求范围内，才继续进入该阶段。对于 DEFER 或 REJECT，则停止。结论即为验收契约；此处无需制定实现计划。