LumioGames brainstorming — 把想法变成有共识的设计
先有被认可的设计，再有任何实现。
范围说明：要不要走本技能由主 loop 判定——小而清楚的改动直接做，不走设计环节。一旦进入本技能就按流程走；中途发现其实不需要设计，说明并交回。设计本身按复杂度伸缩：简单的东西几句话就是一份合格的设计。
流程
- 摸清项目上下文——相关文件、文档、最近提交。若请求横跨多个独立子系统，先说明，帮用户拆成子项目，再脑暴第一个；每个子项目各走一遍「设计 → 拆单 → 实现」。
- 一次只问一个澄清问题——目的、约束、成功判据。优先给多选项。宿主有原生的规划模式 / 提问工具就用它。
- 提出 2–3 个方案并比较取舍，先摆推荐项。坚决 YAGNI。在既有代码库里遵循既有模式，只带进这项工作本身需要的定向改进——不做无关重构。
- 分节呈现设计（架构、组件、数据流、错误处理、测试），每节按其复杂度定篇幅，逐节取得认可。
- 写下来（见下），自审，再交用户审阅书面稿。
- 交棒给
workflow-planning拆单落单。这是本技能之后唯一会调用的技能。
设计落在哪里
设计文档就是功能活文档的第一版——没有单独的 spec 文件，也没有事后再搬一次的沉淀步骤：
- 功能类工作：项目的
.spec/knowledge/features/<topic>.md，用定稿口吻（写它是什么，不写讨论过程），frontmatter 照项目的模板，状态从「设计中」起步并登记进.spec/knowledge/README.md导航；状态随实现推进而流转，文档本身不挪位置。 - 一次性工程任务（没有长期存在的东西要描述）：不建功能文档；设计作为需求单正文的一节，随
workflow-planning落单。 - 取舍、被否方案、「为什么」：项目的
.spec/decisions/下新增一份 ADR。功能文档只保留设计现状。 - 任务真值只有 Workflow 单：设计里凡是要有人去做的事，由
workflow-planning落成单，文档里引用单号；不在文档里另开待办清单。 - 讨论过程本身不入库。用户对文档位置有偏好时以用户为准。
- 提交设计文档。
交用户之前先自审：占位符（「待定」「稍后补」、含糊的需求）→ 补实；内部矛盾 → 修掉；范围——是一份实现计划的量，还是需要再拆；歧义——任何能读出两种意思的需求 → 选定一种并写明。就地改，不用再审一轮。
用户审阅门：「设计已写入并提交到 <路径>，请先审阅，再拆单。」等待；按要求修改并重跑自审；获认可才继续。