name: 头脑风暴 description: “在进行任何创意工作之前必须使用此技能 - 创建功能、构建组件、添加功能或修改行为。在实施之前探索用户意图、需求和设计。”

将想法转化为设计

概述

通过自然协作对话帮助将想法转化为完整的设计和规范。

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

<HARD-GATE> 在呈现设计并用户批准之前，请勿调用任何实施技能、编写任何代码、搭建任何项目或采取任何实施行动。这适用于每个项目，无论感知到的简单性如何。 </HARD-GATE>

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

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

检查清单

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

探索项目上下文 — 检查文件、文档、最近提交
提出澄清问题 — 逐个问题，理解目的/约束/成功标准
提出2-3种方法 — 包括权衡和您的推荐
呈现设计 — 按复杂性分节，每节后获取用户批准
编写设计文档 — 保存到 docs/plans/YYYY-MM-DD-<topic>-design.md 并提交
过渡到实施 — 调用写作计划技能创建实施计划

流程流

digraph brainstorming {
    "探索项目上下文" [shape=box];
    "提出澄清问题" [shape=box];
    "提出2-3种方法" [shape=box];
    "呈现设计节" [shape=box];
    "用户批准设计？" [shape=diamond];
    "编写设计文档" [shape=box];
    "调用写作计划技能" [shape=doublecircle];

    "探索项目上下文" -> "提出澄清问题";
    "提出澄清问题" -> "提出2-3种方法";
    "提出2-3种方法" -> "呈现设计节";
    "呈现设计节" -> "用户批准设计？";
    "用户批准设计？" -> "呈现设计节" [label="否，修订"];
    "用户批准设计？" -> "编写设计文档" [label="是"];
    "编写设计文档" -> "调用写作计划技能";
}

终端状态是调用写作计划。 请勿调用前端设计、MCP构建器或任何其他实施技能。头脑风暴后调用的唯一技能是写作计划。

过程

理解想法：

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

探索方法：

提出2-3种不同方法，包括权衡
以对话方式呈现选项，包括您的推荐和推理
以您的推荐选项为首，并解释原因

呈现设计：

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

设计后

文档：

将验证的设计写入 docs/plans/YYYY-MM-DD-<topic>-design.md
如果可用，使用风格元素：清晰简洁写作技能
将设计文档提交到git

实施：

调用写作计划技能创建详细实施计划
请勿调用任何其他技能。写作计划是下一步。

关键原则

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