名称: 头脑风暴描述: “在开始任何创意工作前必须使用 — 创建功能、构建组件、添加功能或修改行为。在实施前探索需求和设计。”

将想法转化为设计

概述

通过自然协作对话，帮助将想法转化为完全成型的设计和规格。

首先理解当前项目上下文，然后逐一提问来完善想法。一旦理解要构建什么，呈现设计并获得用户批准。

<硬性规定> 在呈现设计并获得用户批准之前，不要编写任何代码、搭建任何项目或采取任何实施行动。无论感知到的简单程度如何，这适用于每个项目。 </硬性规定>

反模式：“这太简单了，不需要设计”

每个项目都经历这个过程。待办事项列表、单一功能实用程序、配置更改 — 所有这些都是。“简单”项目是未经检验的假设导致最多浪费工作的地方。设计可以简短（对于真正简单的项目几句话即可），但必须呈现并获得批准。

清单

必须为以下每个项目创建任务并按顺序完成：

探索项目上下文 — 检查文件、文档、最近提交
提出澄清问题 — 逐一提问，理解目的/约束/成功标准
提出2-3种方法 — 带有权衡和你的推荐
呈现设计 — 按复杂性分节呈现，每节后获得用户批准
过渡到实施 — 调用 oac:context-discovery 找到相关标准，然后继续OAC 6阶段工作流

过程流程

digraph brainstorming {
    "探索项目上下文" [shape=box];
    "提出澄清问题" [shape=box];
    "提出2-3种方法" [shape=box];
    "呈现设计部分" [shape=box];
    "用户批准设计？" [shape=diamond];
    "调用 oac:context-discovery" [shape=doublecircle];

    "探索项目上下文" -> "提出澄清问题";
    "提出澄清问题" -> "提出2-3种方法";
    "提出2-3种方法" -> "呈现设计部分";
    "呈现设计部分" -> "用户批准设计？";
    "用户批准设计？" -> "呈现设计部分" [label="不，修订"];
    "用户批准设计？" -> "调用 oac:context-discovery" [label="是"];
}

终端状态是调用 context-discovery。 在加载上下文并遵循OAC工作流之前，不要编写代码。

过程

理解想法：

首先检查当前项目状态（文件、文档、最近提交）
逐一提问来完善想法
可能时偏好多项选择题，但开放式也可以
每条消息只提一个问题 — 如果需要更多探索，将其分解为多个问题
专注于理解：目的、约束、成功标准

探索方法：

提出2-3种不同方法，带有权衡
对话式呈现选项，带有你的推荐和推理
以你的推荐选项开头并解释原因

呈现设计：

一旦相信理解了要构建什么，呈现设计
按复杂性缩放每节：如果直截了当，几句话；如果 nuanced，最多200-300字
每节后询问是否正确
涵盖：架构、组件、数据流、错误处理、测试
如果有什么不清楚，准备好回去澄清

设计之后

实施：

调用 oac:context-discovery 找到相关上下文文件和标准
然后遵循OAC 6阶段工作流（阶段1已完成 — 你有设计）

关键原则

一次一个问题 — 不要用多个问题压倒
偏好多项选择 — 可能时比开放式更容易回答
无情地应用YAGNI — 从所有设计中移除不必要功能
探索替代方案 — 在确定前总是提出2-3种方法
增量验证 — 呈现设计，在继续前获得批准
保持灵活 — 当有什么不清楚时，回去澄清

名称: 头脑风暴 描述: “在开始任何创意工作前必须使用 — 创建功能、构建组件、添加功能或修改行为。在实施前探索需求和设计。”