Brainstorming

brainstorming — 把想法变成有共识的设计

先有被认可的设计，再有任何实现。

在设计呈现给用户并获认可之前，不调任何实现类技能、不写代码、不搭脚手架、不做任何实现动作。

范围说明：要不要走本技能由主 loop 判定——小而清楚的改动直接做，不走设计环节。一旦进入本技能就按流程走；中途发现其实不需要设计，说明并交回。设计本身按复杂度伸缩：简单的东西几句话就是一份合格的设计。

流程

1. 摸清项目上下文——相关文件、文档、最近提交。若请求横跨多个独立子系统，先说明，帮用户拆成子项目，再脑暴第一个；每个子项目各走一遍「设计 → 拆单 → 实现」。
2. 一次只问一个澄清问题——目的、约束、成功判据。优先给多选项。宿主有原生的规划模式 / 提问工具就用它。
3. 提出 2–3 个方案并比较取舍，先摆推荐项。坚决 YAGNI。在既有代码库里遵循既有模式，只带进这项工作本身需要的定向改进——不做无关重构。
4. 分节呈现设计（架构、组件、数据流、错误处理、测试），每节按其复杂度定篇幅，逐节取得认可。
5. 写下来（见下），自审，再交用户审阅书面稿。
6. 交棒给 workflow-planning 拆单落单。这是本技能之后唯一会调用的技能。

设计落在哪里

设计文档就是功能活文档的第一版——没有单独的 spec 文件，也没有事后再搬一次的沉淀步骤：

• 功能类工作：项目的 .spec/knowledge/features/.md，用定稿口吻（写它是什么，不写讨论过程），frontmatter 照项目的模板，状态从「设计中」起步并登记进 .spec/knowledge/README.md 导航；状态随实现推进而流转，文档本身不挪位置。
• 一次性工程任务（没有长期存在的东西要描述）：不建功能文档；设计作为需求单正文的一节，随 workflow-planning 落单。
• 取舍、被否方案、「为什么」：项目的 .spec/decisions/ 下新增一份 ADR。功能文档只保留设计现状。
• 任务真值只有 Workflow 单：设计里凡是要有人去做的事，由 workflow-planning 落成单，文档里引用单号；不在文档里另开待办清单。
• 讨论过程本身不入库。用户对文档位置有偏好时以用户为准。
• 提交设计文档。

交用户之前先自审：占位符（「待定」「稍后补」、含糊的需求）→ 补实；内部矛盾 → 修掉；范围——是一份实现计划的量，还是需要再拆；歧义——任何能读出两种意思的需求 → 选定一种并写明。就地改，不用再审一轮。

用户审阅门：「设计已写入并提交到 ``，请先审阅，再拆单。」等待；按要求修改并重跑自审；获认可才继续。

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: LumioGames
• Source: LumioGames/workflow-plugin
• License: MIT
• Homepage: https://workflow.games

Install and usage instructions live in the source repository linked above.