什么是 头脑风暴？

头脑风暴技能作为初始用户请求与主动编码之间的战略缓冲区。通过利用苏格拉底式提问，它强制深入探讨问题解决方案，确保开发人员和 AI 代理在意图、用户需求和成功标准上达成一致。它是维护 Openclaw Skills 生态系统内高质量代码的关键组件。

该技能通过展示多种技术方案来防止范围蔓延和架构债务等常见陷阱。每个方案都会根据复杂性和权衡进行评估，从而实现明智的决策。该过程最终形成一份结构化的设计文档，作为后续开发阶段的唯一事实来源。

下载入口:https://github.com/openclaw/skills/tree/main/skills/nefas11/brainstorming-2

安装与下载

1. ClawHub CLI

从源直接安装技能的最快方式。

2. 手动安装

将技能文件夹复制到以下位置之一

优先级：工作区 > 本地 > 内置

3. 提示词安装

将此提示词复制到 OpenClaw 即可自动安装。

头脑风暴 应用场景

• 当用户请求模糊时，例如“优化 UI”或“提高性能”。
• 在处理影响多个系统组件或服务的复杂功能之前。
• 当高层设计决策需要权衡多种架构方案时。
• 为了建立成功标准并在生命周期早期识别潜在的边缘情况。

1. 理解意图：该技能启动苏格拉底式对话，针对问题、用户画像和约束条件提出澄清性问题。
2. 探索替代方案：生成 2-3 种不同的技术方案，详细说明每种方案的优缺点和复杂性评分。
3. 设计文档：一旦选定方案，它将按照标准化模板生成一份全面的设计文档。
4. 技能衔接：完成的设计文档将传递给规划技能，以启动实施序列。

头脑风暴 配置指南

要将此技能集成到您的本地环境中，请确保您的项目目录结构支持文档存储。此技能作为 Openclaw Skills 核心套件的一部分运行，并需要特定的输出目录。

mkdir -p docs/design

头脑风暴 数据架构与分类体系

头脑风暴技能维护着设计决策的结构化历史。所有输出均以 Markdown 格式存储在标准化目录中，以确保兼容性和可读性。

每份文档都包含一个成功标准核对表，以确保实施方案可以根据原始意图进行验证。

name: brainstorming
description: Socratic design refinement before coding. Use when user requests feature without clear spec.

Brainstorming Skill

When to Use

Trigger BEFORE writing code when:

• User request is vague ("make it better", "add feature X")
• Complex feature with multiple approaches
• Design decisions impact multiple components

Workflow

Step 1: Understand Intent

Ask clarifying questions:

• What problem are we solving?
• Who is the user?
• What's the success criteria?
• What constraints exist? (time, compatibility, dependencies)

Step 2: Explore Alternatives

Present 2-3 approaches:

• Approach A (simple): [description]
• Approach B (robust): [description]
• Approach C (future-proof): [description]

For each: Pros, Cons, Complexity (1-5)

Step 3: Design Document

After user picks approach, create design doc:

# Feature: [Name]

## Problem
[1-2 sentences]

## Solution
[Chosen approach, 3-5 sentences]

## Components Affected
- [Component 1]: [Change description]
- [Component 2]: [Change description]

## Testing Strategy
- Unit tests: [What to test]
- Integration tests: [What to test]

## Edge Cases
- [Case 1]
- [Case 2]

## Success Criteria
- [ ] [Criterion 1]
- [ ] [Criterion 2]

Save to: docs/design/YYYY-MM-DD-feature-name.md

Step 4: Transition to Planning

Pass design doc to writing-plans skill.

Anti-Patterns

? Jump straight to implementation ? Present only one approach ? Skip edge case discussion ? Forget to save design doc

Example

User: "Add caching"

Bad:

I'll add Redis caching to the API.

Good:

Let me understand the requirements first:

1. What should be cached? (API responses, DB queries, computed results?)
2. What's the invalidation strategy? (TTL, event-based, manual?)
3. What's the acceptable staleness? (seconds, minutes, hours?)

Based on your answers, I'll present 3 approaches with trade-offs.