brainstorming

将构想转化为设计

概述

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

首先了解当前项目的背景，然后一次提出一个问题，以完善构想。了解要构建的内容后，展示设计并征求用户批准。

在展示设计并获得用户批准之前，**不得**调用任何实现技能、编写任何代码、搭建任何项目骨架，或采取任何实现行动。无论项目看起来多么简单，这一要求都适用。

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

每个项目都必须遵循此流程。“简单”项目中未经审视的假设最容易造成大量无谓工作。设计可以简短，但必须展示设计并获得批准。

检查清单

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

1. 了解项目背景 — 检查文件、文档和近期提交
2. 提出澄清问题 — 一次一个，了解目的、限制条件和成功标准
3. 提出 2-3 种方案 — 说明取舍并给出推荐方案
4. 展示设计 — 根据复杂程度分节说明，包括测试策略、错误处理方案和验证标准（参见下方的质量原则），并在每个部分结束后征求用户批准
5. 编写设计文档 — 保存到 .claude/plans/YYYY-MM-DD-<topic>-design.md 并提交
6. 转入实现阶段 — 调用 writing-plans 技能来创建实现计划

质量原则

此技能生成的计划应在设计阶段考虑以下事项：

• 测试策略：references/tdd-principles.md
• 错误处理与调试方案：references/debugging-principles.md
• 验证标准：references/verification-principles.md

流程

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 或任何其他实现技能。

有关详细流程步骤（提问技巧、设计展示、文档编写、关键原则），请参阅 references/detailed-process.md。