brainstorming

头脑风暴：从想法到设计

通过自然的协作对话，把想法变成完整的设计和需求文档。

先了解当前项目上下文，然后一次问一个问题来细化想法。理解要构建什么之后，展示设计并获得用户确认。

在展示设计并获得用户确认之前，绝对不要调用任何实现 skill、写任何代码、搭建任何项目或执行任何实现操作。无论项目看起来多简单，都适用此规则。

反模式："这个太简单了不需要设计"

每个项目都要走这个流程。一个 todo list、一个单函数工具、一个配置变更 — 全部都要。"简单"项目恰恰是未经审视的假设导致最多浪费的地方。设计可以很短（真正简单的项目几句话就够），但你必须展示它并获得确认。

Checklist

你必须为以下每项创建 task 并按顺序完成：

1. 探索项目上下文 — 检查文件、文档、最近提交
2. 提供可视化伴侣（如果主题涉及视觉问题）— 这是独立的消息，不与澄清问题合并。参见下方「可视化伴侣」部分。
3. 提问澄清 — 一次一个问题，理解目的/约束/成功标准
4. 提出 2-3 个方案 — 含权衡对比和你的推荐
5. 展示设计 — 按复杂度分段展示，每段获得用户确认
6. 写需求文档 — 保存到 docs/harness/feature/YYYY-MM-DD-<topic>.md
7. 需求自检 — 快速检查占位符、矛盾、歧义、范围（见下方）
8. 用户审阅需求 — 请用户审阅文件后再继续
9. 跳转到实现 — 调用 writing-plans skill 创建实现计划

流程

理解想法：

• 先检查当前项目状态（文件、文档、最近提交）
• 在详细提问之前，评估范围：如果请求描述了多个独立子系统（如"构建一个包含聊天、文件存储、计费和分析的平台"），立即标记。不要花问题去细化一个需要先分解的项目。
• 如果项目太大无法用单个需求覆盖，帮用户分解为子项目：独立的部分是什么、它们如何关联、构建顺序是什么？然后对第一个子项目走正常设计流程。每个子项目有自己的 feature → plan → 实现周期。
• 对于范围合适的项目，一次问一个问题来细化想法
• 尽量用选择题，但开放式问题也可以
• 每条消息只问一个问题 — 如果某个主题需要更多探索，拆成多个问题
• 聚焦理解：目的、约束、成功标准
• 阅读 docs/harness/standard/ 了解项目编码规范
• 阅读 docs/harness/design/ 了解现有架构（如果存在）

探索方案：

• 提出 2-3 个不同方案及其权衡
• 以对话方式展示选项，附带你的推荐和理由
• 先展示推荐方案并解释原因

展示设计：

• 当你认为理解了要构建什么，展示设计
• 按复杂度调整每段篇幅：简单的几句话，复杂的 200-300 字
• 每段之后询问是否正确
• 覆盖：架构、组件、数据流、错误处理、测试
• 准备好回头澄清不清楚的地方

隔离性和清晰性设计：

• 把系统拆成更小的单元，每个有明确的目的，通过定义良好的接口通信，可以独立理解和测试
• 对于每个单元，你应该能回答：它做什么、怎么用它、它依赖什么？
• 有人能不读内部实现就理解一个单元做什么吗？你能改内部实现而不破坏使用者吗？如果不能，边界需要改进。
• 更小、边界清晰的单元也更好处理 — 你对能在上下文中完整容纳的代码推理更好，编辑也更可靠。当文件变大时，通常说明它做了太多事。

在现有代码库中工作：

• 在提出变更之前探索当前结构。遵循现有模式。
• 如果现有代码有影响工作的问题（如文件过大、边界不清、职责纠缠），把针对性改进纳入设计 — 就像好的开发者改进正在工作的代码一样。
• 不要提出无关的重构。聚焦于服务当前目标。

设计之后

文档：

• 把验证过的设计（需求）写到 docs/harness/feature/YYYY-MM-DD-<topic>.md
  • （用户对需求位置的偏好覆盖此默认值）
• 不要 git commit — 用户手动管理

需求自检： 写完需求文档后，用全新视角检查：

1. 占位符扫描： 有"TBD"、"TODO"、不完整的部分或模糊的需求吗？修复它们。
2. 内部一致性： 各部分有矛盾吗？架构和功能描述匹配吗？
3. 范围检查： 是否足够聚焦可以用单个实现计划？还是需要分解？
4. 歧义检查： 有需求可以被两种方式理解吗？如果有，选一种并明确。

发现问题直接修复。不需要重新审阅 — 修完继续。

用户审阅关卡： 自检通过后，请用户审阅写好的需求：

"需求已写入 <path>。请审阅，如果要在开始写实现计划之前做任何修改，请告诉我。"

等待用户回复。如果用户要求修改，修改后重新自检。只在用户确认后才继续。

实现：

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

关键原则

• 一次一个问题 — 不要用多个问题淹没用户
• 优先选择题 — 比开放式问题更容易回答
• 严格 YAGNI — 从所有设计中移除不必要的功能
• 探索替代方案 — 在确定之前总是提出 2-3 个方案
• 增量验证 — 展示设计，获得确认后再继续
• 保持灵活 — 发现不清楚的地方回头澄清

可视化伴侣

基于浏览器的伴侣，用于在头脑风暴中展示模型、图表和视觉选项。作为工具可用 — 不是模式。接受伴侣意味着它可用于受益于视觉处理的问题；这不意味着每个问题都通过浏览器。

提供伴侣： 当你预期即将到来的问题涉及视觉内容（模型、布局、图表）时，提供一次以获得同意：

"我们正在讨论的一些内容如果能在浏览器中展示给你看可能更容易理解。我可以在讨论过程中制作模型、图表、对比和其他视觉内容。这个功能还比较新，可能会消耗较多 token。要试试吗？（需要打开一个本地 URL）"

此提供必须是独立消息。 不要与澄清问题、上下文摘要或任何其他内容合并。消息应只包含上述提供内容，不包含其他内容。等待用户回复后再继续。如果用户拒绝，使用纯文本头脑风暴。

逐问题决策： 即使用户接受了伴侣，也要对每个问题分别决定是否使用浏览器或终端。判断标准：用户看到它会比阅读它理解得更好吗？

• 使用浏览器 处理本来就是视觉的内容 — 模型、线框图、布局对比、架构图、并排视觉设计
• 使用终端 处理文本内容 — 需求问题、概念选择、权衡列表、A/B/C/D 文本选项、范围决策

UI 主题的问题不自动成为视觉问题。"在这个上下文中个性意味着什么？"是概念问题 — 用终端。"哪个向导布局更好？"是视觉问题 — 用浏览器。

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