brainstorming

将构想转化为设计

通过自然的协作式对话，帮助将想法打磨成完整的设计和规格说明。

首先，判断请求需要多少流程，然后按相应路径推进：了解背景、完善构想、提出设计，并获得你的合作伙伴的批准。

在告诉你的合作伙伴你打算做什么并获得批准之前，不要调用任何实现技能、编写代码、搭建项目框架，也不要采取任何实现行动。以下每条路径上的每项任务都适用此规则——流程的繁简可以随任务调整，但审批关卡不可省略。

在此技能期间，绝不能调用 EnterPlanMode 或 ExitPlanMode。 此技能在普通模式下运行。计划模式会限制 Write/Edit 工具，且无法顺利退出。需要进行结构化规划时，请改用 writing-plans 技能。

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

三种路径

在提出第一个问题之前，先判断请求属于哪种类型，并明确说出你的判断——“这看起来范围明确，所以我会在这里给出简短设计，而不是编写规格说明”——让你的合作伙伴可以提出异议：

• Spike —— 可行性问题（“我们能不能……”“是否可以……”“快速粗略地做就行”），其产出是答案，而非需要保留的代码。用 2–3 句话说明问题和计划尝试的内容，征得同意，然后以满足正确性所需的最低成本进行探查。无需设计文档，也无需规格文件。以建议的形式汇报发现；任何构建出的内容都必须标注为一次性产物。
• Bounded —— 对本仓库中已有代码进行范围明确的修改：新增一个标志、小型端点、单文件修复。仅了解应用类型还不够；只有要修改的流程已经存在于此、可供查看，才算范围明确。如果没有现成流程可供修改，该任务就不属于此类。提出关键的澄清问题，在聊天中给出简短设计（从几句话到几段简短文字），然后停止。只有你的合作伙伴同意该设计后，才能开始实现——范围明确任务的审批关卡与架构级任务同样严格。无需规格文件，也无需实现计划文档。
• Architectural —— 新项目、新子系统、重构组件之间的协作方式，或更改其他部分所依赖的接口。遵循完整流程：提问、提出方案、分章节设计、撰写规格说明，然后使用 writing-plans 技能。

如果无法确定应走哪条路径，就选择流程更繁复的那条。路径只能向上调整：如果在任务中发现了隐藏的复杂性，就升级路径——停下来说明情况，并提高流程级别。任务进行中不得降低级别。

反面模式：“太简单，不需要审批”

每条路径都必须在实现之前，由你的合作伙伴批准你的意图。待办事项清单、单函数实用工具、配置更改——设计也许只需在聊天中写两句话，但你必须提出设计并获得批准。“简单”的任务最容易因未经审视的假设而造成大量返工。简单程度可以影响产物的规模，但绝不能影响审批要求。

警示信号

想法	实际情况
“这太简单了，不需要设计”	简单意味着设计简短，而不是不做设计。在聊天中用两句话说明，然后获得批准。
“我会把它称为有界任务，跳过规格说明”	找个标签来跳过工作，本身就是疑虑的表现——选择更严谨的路径。
“任务有界，设计也显而易见——趁他们阅读时我先开始”	门槛是获得批准，而不是设计的长度。先展示设计，然后停下，直到听到肯定答复。
“我了解这类应用，所以任务有界”	有界与否取决于代码仓库，而不是你对它的熟悉程度。新项目没有现有流程——这属于架构性任务。
“试验验证成功了，所以我会保留代码”	试验的产出是答案。保留代码是新的请求——先分类。
“任务范围扩大了，但我快做完了——不必重新分类”	隐藏的复杂性会在任务进行中升级路径。停下来说明情况。
“他们批准了试验，所以后续修改也获批了”	每项任务都要单独分类并单独获得批准。

检查清单

先分类，说明所选路径，然后为路径上的每个事项创建任务，并按顺序完成。

试验：

1. 了解项目背景——掌握足够的信息，以便界定探查范围
2. 说明问题和探查计划——用 2-3 句话
3. 获得批准——对方点头即可
4. 开展调查——在保证正确性的前提下尽可能节省成本
5. 报告发现——给出建议；将任何已构建的内容标明为一次性成果

有界任务：

1. 了解项目背景——检查文件、文档和近期提交
2. 提出澄清问题——一次一个，只问重要的问题
3. 在聊天中展示简短设计——方案、涉及的文件和测试
4. 获得批准——停下并等待明确的肯定答复；展示设计后立即开始，就等于跳过了门槛
5. 实施——按正常开发工作流推进（适用 TDD）；不编写计划文档

架构性任务：

1. 了解项目背景——检查文件、文档和近期提交
2. 在恰当时机提供可视化辅助工具——不要一开始就提供。只有当某个问题确实通过展示比通过描述更清晰时，才在那时提供（单独发送一条消息）；获得批准后，浏览器标签页会为你打开。如果始终没有出现需要可视化的问题，就不要提供。请参阅下方的“可视化辅助工具”章节。
3. 提出澄清问题——一次一个，了解目的、约束和成功标准
4. 提出 2-3 种方案——说明权衡并给出你的建议
5. 展示设计——根据复杂程度分节展示，每节之后都要获得用户批准
6. 编写设计文档——保存至 docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md 并提交
7. 自行审查规格说明——快速检查占位符、矛盾、歧义和范围（见下文）
8. 由用户审查书面规格说明——在继续之前，请用户审查规格说明文件
9. 转入实施阶段——调用 writing-plans skill 创建实施计划

流程

digraph brainstorming {
    "Classify: spike / bounded / architectural" [shape=diamond];
    "Present question + probe (2-3 sentences)" [shape=box];
    "Ask clarifying questions (bounded)" [shape=box];
    "Present short design in chat" [shape=box];
    "Human approves?" [shape=diamond];
    "Investigate; report recommendation" [shape=doublecircle];
    "Implement via normal workflow (no plan doc)" [shape=doublecircle];
    "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];
    "Spec self-review\n(fix inline)" [shape=box];
    "User reviews spec?" [shape=diamond];
    "Invoke writing-plans skill" [shape=doublecircle];
    "Hidden complexity? Upgrade path" [shape=box];

    "Classify: spike / bounded / architectural" -> "Present question + probe (2-3 sentences)" [label="spike"];
    "Classify: spike / bounded / architectural" -> "Ask clarifying questions (bounded)" [label="bounded"];
    "Classify: spike / bounded / architectural" -> "Explore project context" [label="architectural"];
    "Present question + probe (2-3 sentences)" -> "Human approves?";
    "Ask clarifying questions (bounded)" -> "Present short design in chat";
    "Present short design in chat" -> "Human approves?";
    "Human approves?" -> "Investigate; report recommendation" [label="spike: yes"];
    "Human approves?" -> "Implement via normal workflow (no plan doc)" [label="bounded: yes"];
    "Hidden complexity? Upgrade path" -> "Classify: spike / bounded / architectural";
    "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" -> "Spec self-review\n(fix inline)";
    "Spec self-review\n(fix inline)" -> "User reviews spec?";
    "User reviews spec?" -> "Write design doc" [label="changes requested"];
    "User reviews spec?" -> "Invoke writing-plans skill" [label="approved"];
}

终止状态由路径决定。 架构性任务：头脑风暴后唯一可以调用的 skill 是 writing-plans——绝不能调用 frontend-design、mcp-builder 或任何其他实施 skill。有界任务：获得批准后，直接按照正常开发工作流推进实施；不编写计划文档。试验：终止状态是报告建议。

流程

以下小节适用于范围明确和架构设计路径（探索性研究到“展示探测结果，获得认可”就结束）。从探索方案开始的章节属于架构设计路径的深度内容——对于范围明确的工作，了解背景、提出几个问题，再进行简短的聊天内设计，就是完整流程。

理解想法：

• 先查看当前项目状态（文件、文档、近期提交）
• 在提出详细问题之前，先评估范围：如果请求描述了多个相互独立的子系统（例如“构建一个包含聊天、文件存储、计费和分析的平台”），请立即指出这一点。不要花时间通过提问细化一个需要先拆分的项目。
• 如果项目太大，无法用一份规格说明涵盖，就帮助用户拆分为多个子项目：哪些部分彼此独立，它们之间有何关系，应按什么顺序构建？然后按照常规设计流程，为第一个子项目集思广益。每个子项目都有自己的规格说明 → 计划 → 实施周期。
• 对于范围合适的项目，每次提出一个问题，逐步明确想法
• 尽可能优先使用选择题，但开放式问题也可以
• 每条消息只问一个问题——如果某个主题需要进一步探讨，就拆分成多个问题
• 重点了解：目的、约束条件、成功标准

探索方案：

• 提出 2-3 种不同方案，并说明各自的取舍
• 以对话式方式介绍选项，同时给出你的建议和理由
• 优先介绍你推荐的方案，并解释原因
• 严格遵循 YAGNI 原则——从每种方案和设计中删去不必要的功能

展示设计：

• 确信自己已理解要构建的内容后，展示设计
• 根据复杂程度调整每个部分的篇幅：简单内容用几句话说明，复杂内容最多写 200-300 个词
• 每介绍完一个部分，都询问目前看来是否合适
• 涵盖：架构、组件、数据流、错误处理、测试
• 如果有些内容不清楚，随时返回并进一步澄清

按隔离性和清晰度设计：

• 将系统拆分成更小的单元，每个单元都有明确的用途，通过定义清晰的接口进行通信，并且可以独立理解和测试
• 对于每个单元，你都应该能够回答：它做什么、如何使用、依赖什么？
• 不看单元内部实现，别人能理解它的作用吗？你能在不影响使用方的情况下修改内部实现吗？如果不能，就需要改进边界划分。
• 较小且边界清晰的单元也更便于你开展工作——你能更好地推理那些可以一次放入上下文中的代码；文件职责越集中，编辑也越可靠。文件变得庞大时，通常说明它承担了太多职责。

在现有代码库中工作：

• 提出修改建议前，先了解当前结构。遵循现有模式。
• 如果现有代码中的问题会影响工作（例如文件变得过于庞大、边界不清晰、职责纠缠），就将有针对性的改进纳入设计——优秀开发者会在处理代码时顺手改进代码。
• 不要提出无关的重构。专注于有助于实现当前目标的内容。

设计之后（架构路径）

文档：

• 将已验证的设计（规格说明）写入 docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md
  • （用户对规格说明存放位置的偏好优先于此默认设置）
• 如果可用，请使用 elements-of-style:writing-clearly-and-concisely 技能
• 将设计文档提交到 git

规格说明自审： 写完规格说明文档后，以全新的视角审阅它：

1. 占位内容检查： 是否有“TBD”“TODO”、未完成的章节或含糊的要求？请修正。
2. 内部一致性： 各章节是否存在相互矛盾之处？架构是否符合功能描述？
3. 范围检查： 内容是否足够聚焦，可以制定单个实施计划，还是需要拆分？
4. 歧义检查： 是否有任何要求可能被解读为两种不同的含义？如果有，请选定一种并明确说明。

直接修正发现的问题。无需重新审阅，修正后继续即可。

用户审阅关卡： 通过规格说明审阅循环后，请用户审阅已编写的规格说明，然后再继续：

“规格说明已编写并提交到 <path>。请审阅，并告知我在开始编写实施计划之前是否需要进行任何更改。”

等待用户回复。如果用户要求修改，请按要求修改，并重新运行规格说明审阅循环。只有用户批准后才能继续。

实施：

• 调用 writing-plans 技能，创建详细的实施计划
• 不要调用任何其他技能。writing-plans 是下一步。

视觉辅助工具

一款基于浏览器的辅助工具，可在头脑风暴期间展示模型图、图表和视觉选项。它以工具形式提供，而非一种模式。接受视觉辅助工具后，意味着在适合视觉呈现的问题中可以使用它；并不意味着每个问题都要通过浏览器处理。

适时提供辅助工具： 不要一开始就提供。等到遇到确实用图示比文字更容易说明的问题时再提供——必须是实际的模型图／布局／图表问题，而不仅仅是 UI 主题。第一次遇到这种情况时，请在单独一条消息中提供：

“接下来的内容用图示可能更容易理解——我可以在过程中通过浏览器标签页展示模型图、图表和对比。这项功能还比较新，而且可能消耗较多 token。你需要我这样做吗？我会为你打开它。”

此邀请必须单独成条消息。 消息中只能包含邀请，不得包含澄清问题、摘要或其他内容。等待用户回复。如果用户接受，请使用 --open 启动服务，以便浏览器自动打开并显示第一个屏幕。如果用户拒绝，则继续仅用文字交流，除非用户之后主动提出，否则不要再次提供。

逐个问题判断： 即使用户接受了辅助工具，也要针对每个问题分别判断使用浏览器还是终端。判断标准是：用户通过观看是否会比通过阅读更容易理解？

• 使用浏览器处理本质上属于视觉内容的事项，例如模型图、线框图、布局对比、架构图、并排展示的视觉设计
• 使用终端处理文字内容，例如需求问题、概念选择、权衡列表、A/B/C/D 文字选项、范围决策

关于 UI 主题的问题不一定属于视觉问题。“此处的 personality 是什么意思？”属于概念问题，应使用终端。“哪种向导布局更好？”属于视觉问题，应使用浏览器。

如果用户同意使用辅助工具，请在继续之前阅读详细指南： skills/brainstorming/visual-companion.md

---

原生任务集成

必需： 在设计期间，使用 Claude Code 的原生任务工具创建结构化任务。

设计验证期间

每验证完一个设计章节，就创建一个包含结构化描述的任务：

TaskCreate:
  subject: "Implement [Component Name]"
  description: |
    **Goal:** [What this component produces]

    **Files:**
    - Create/Modify: [paths identified during design]

    **Acceptance Criteria:**
    - [ ] [Criterion from design validation]
    - [ ] [Criterion from design validation]

    **Verify:** [How to test this component works]

    ```json:metadata
    {"files": ["path/from/design"], "acceptanceCriteria": ["criterion 1", "criterion 2"], "modelTier": "mechanical|standard|frontier"}
    ```
  activeForm: "Implementing [Component Name]"

这些任务将在编写计划时补充步骤和验证命令。完整格式请参阅 skills/shared/task-format-reference.md。

记录所有任务 ID，以便设置依赖关系。

所有组件验证完毕后

设置依赖关系：

TaskUpdate:
  taskId: [dependent-task-id]
  addBlockedBy: [prerequisite-task-ids]

交接前

运行 TaskList，显示包含依赖关系的完整任务结构。