brainstorming

您必须在任何创造性工作之前使用它 - 创建功能、构建组件、添加功能或修改行为。在实施之前探索用户意图、要求和设计。

# Brainstorming Ideas Into Designs

## Overview

Help turn ideas into fully formed designs and specs through natural collaborative dialogue.

Start by understanding the current project context, then ask questions one at a time to refine the idea. Once you understand what you're building, present the design and get user approval.

<HARD-GATE>
Do NOT invoke any implementation skill, write any code, scaffold any project, or take any implementation action until you have presented a design and the user has approved it. This applies to EVERY project regardless of perceived simplicity.
</HARD-GATE>

## Anti-Pattern: "This Is Too Simple To Need A Design"

Every project goes through this process. A todo list, a single-function utility, a config change — all of them. "Simple" projects are where unexamined assumptions cause the most wasted work. The design can be short (a few sentences for truly simple projects), but you MUST present it and get approval.

## Checklist

You MUST create a task for each of these items and complete them in order:

1. **Explore project context** — check files, docs, recent commits
2. **Ask clarifying questions** — one at a time, understand purpose/constraints/success criteria
3. **Propose 2-3 approaches** — with trade-offs and your recommendation
4. **Present design** — in sections scaled to their complexity, get user approval after each section
5. **Write design doc** — save to `docs/plans/YYYY-MM-DD-<topic>-design.md` and commit
6. **Transition to implementation** — invoke writing-plans skill to create implementation plan

## Process Flow

```dot
digraph brainstorming {
    "Explore project context" [shape=box];
    "Ask clarifying questions" [shape=box];
    "Propose 2-3 approaches" [shape=box];
    "Present design sections" [shape=box];
    "User approves design?" [shape=diamond];
    "Write design doc" [shape=box];
    "Invoke writing-plans skill" [shape=doublecircle];

    "Explore project context" -> "Ask clarifying questions";
    "Ask clarifying questions" -> "Propose 2-3 approaches";
    "Propose 2-3 approaches" -> "Present design sections";
    "Present design sections" -> "User approves design?";
    "User approves design?" -> "Present design sections" [label="no, revise"];
    "User approves design?" -> "Write design doc" [label="yes"];
    "Write design doc" -> "Invoke writing-plans skill";
}
```

**The terminal state is invoking writing-plans.** Do NOT invoke frontend-design, mcp-builder, or any other implementation skill. The ONLY skill you invoke after brainstorming is writing-plans.

## The Process

**Understanding the idea:**
- Check out the current project state first (files, docs, recent commits)
- Ask questions one at a time to refine the idea
- Prefer multiple choice questions when possible, but open-ended is fine too
- Only one question per message - if a topic needs more exploration, break it into multiple questions
- Focus on understanding: purpose, constraints, success criteria

**Exploring approaches:**
- Propose 2-3 different approaches with trade-offs
- Present options conversationally with your recommendation and reasoning
- Lead with your recommended option and explain why

**Presenting the design:**
- Once you believe you understand what you're building, present the design
- Scale each section to its complexity: a few sentences if straightforward, up to 200-300 words if nuanced
- Ask after each section whether it looks right so far
- Cover: architecture, components, data flow, error handling, testing
- Be ready to go back and clarify if something doesn't make sense

## After the Design

**Documentation:**
- Write the validated design to `docs/plans/YYYY-MM-DD-<topic>-design.md`
- Use elements-of-style:writing-clearly-and-concisely skill if available
- Commit the design document to git

**Implementation:**
- Invoke the writing-plans skill to create a detailed implementation plan
- Do NOT invoke any other skill. writing-plans is the next step.

## Key Principles

- **One question at a time** - Don't overwhelm with multiple questions
- **Multiple choice preferred** - Easier to answer than open-ended when possible
- **YAGNI ruthlessly** - Remove unnecessary features from all designs
- **Explore alternatives** - Always propose 2-3 approaches before settling
- **Incremental validation** - Present design, get approval before moving on
- **Be flexible** - Go back and clarify when something doesn't make sense

---

## 中文说明

# 将想法头脑风暴成设计

## 概述

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

首先理解当前的项目上下文，然后每次提一个问题来打磨想法。一旦你理解了要构建的内容，就呈现设计并获得用户批准。

<HARD-GATE>
在你呈现设计并且用户已批准之前，切勿调用任何实现类技能、编写任何代码、搭建任何项目脚手架或采取任何实现动作。无论项目看起来多么简单，这一点都适用于每一个项目。
</HARD-GATE>

## 反模式："这太简单，不需要设计"

每个项目都要经历这个流程。一个待办清单、一个单函数工具、一处配置变更——全都如此。"简单"项目恰恰是未经审视的假设造成最多无用功的地方。设计可以很短（对真正简单的项目只需几句话），但你必须呈现它并获得批准。

## 清单

你必须为以下每一项创建一个任务，并按顺序完成它们：

1. **探索项目上下文** —— 检查文件、文档、近期提交
2. **提出澄清性问题** —— 每次一个，理解目的/约束/成功标准
3. **提出 2-3 种方案** —— 附带权衡取舍及你的推荐
4. **呈现设计** —— 按各部分复杂度分节呈现，每一节之后获得用户批准
5. **编写设计文档** —— 保存到 `docs/plans/YYYY-MM-DD-<topic>-design.md` 并提交
6. **过渡到实现** —— 调用 writing-plans 技能来创建实现计划

## 流程图

```dot
digraph brainstorming {
    "Explore project context" [shape=box];
    "Ask clarifying questions" [shape=box];
    "Propose 2-3 approaches" [shape=box];
    "Present design sections" [shape=box];
    "User approves design?" [shape=diamond];
    "Write design doc" [shape=box];
    "Invoke writing-plans skill" [shape=doublecircle];

    "Explore project context" -> "Ask clarifying questions";
    "Ask clarifying questions" -> "Propose 2-3 approaches";
    "Propose 2-3 approaches" -> "Present design sections";
    "Present design sections" -> "User approves design?";
    "User approves design?" -> "Present design sections" [label="no, revise"];
    "User approves design?" -> "Write design doc" [label="yes"];
    "Write design doc" -> "Invoke writing-plans skill";
}
```

**终止状态是调用 writing-plans。** 切勿调用 frontend-design、mcp-builder 或任何其他实现类技能。头脑风暴之后你唯一可调用的技能就是 writing-plans。

## 流程

**理解想法：**
- 先查看当前的项目状态（文件、文档、近期提交）
- 每次提一个问题来打磨想法
- 尽量优先使用选择题，但开放式问题也可以
- 每条消息只提一个问题——如果某个话题需要更多探索，将其拆分成多个问题
- 聚焦于理解：目的、约束、成功标准

**探索方案：**
- 提出 2-3 种不同方案，附带权衡取舍
- 以对话方式呈现选项，并给出你的推荐及理由
- 以你推荐的选项开头，并解释原因

**呈现设计：**
- 一旦你认为已理解要构建的内容，就呈现设计
- 按各部分复杂度调整篇幅：直白的话几句话即可，细致的话最多 200-300 字
- 每一节之后询问目前看起来是否正确
- 涵盖：架构、组件、数据流、错误处理、测试
- 如果有内容讲不通，随时准备回头澄清

## 设计之后

**文档：**
- 将经过验证的设计写入 `docs/plans/YYYY-MM-DD-<topic>-design.md`
- 如有可用，使用 elements-of-style:writing-clearly-and-concisely 技能
- 将设计文档提交到 git

**实现：**
- 调用 writing-plans 技能来创建详细的实现计划
- 切勿调用任何其他技能。writing-plans 是下一步。

## 关键原则

- **每次一个问题** —— 不要用多个问题让人应接不暇
- **优先选择题** —— 在可能时比开放式问题更容易回答
- **无情地践行 YAGNI** —— 从所有设计中移除不必要的功能
- **探索替代方案** —— 在敲定之前总是提出 2-3 种方案
- **增量式验证** —— 呈现设计，在继续之前获得批准
- **保持灵活** —— 当有内容讲不通时回头澄清