メニュー
当用户明确要求"使用 brainstorming"或"使用 awesome-code"时使用。⚠️ 不适用：用户只是想优化/改进某个功能（应直接修改）、只是询问技能问题（应直接回答）、没有明确使用 brainstorming/awesome-code 的一般性开发。
デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。
インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
直接コマンドでは確認用 Prompt が省略されます。実行前にソースを確認してください。
npx skills add https://github.com/majiayu000/claude-skill-registry --skill brainstormingコマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。
ローカルで確認しますか？SkillsMP が現在取得できるファイルをダウンロードできます。
SOC 職業分類に基づく
SKILL.md を表示中
| name | brainstorming |
| description | 当用户明确要求"使用 brainstorming"或"使用 awesome-code"时使用。⚠️ 不适用：用户只是想优化/改进某个功能（应直接修改）、只是询问技能问题（应直接回答）、没有明确使用 brainstorming/awesome-code 的一般性开发。 |
| metadata | {"short-description":"交互式设计优化","keywords":["brainstorming","awesome-code","交互式设计"],"category":"设计","author":"Bensz Conan","platform":"Claude Code | OpenAI Codex | ChatGPT","iron-law":"NO IMPLEMENTATION WITHOUT DESIGN DISCUSSION FIRST\n"} |
NO IMPLEMENTATION WITHOUT DESIGN DISCUSSION FIRST
违反规则的信件就是违反规则的精神。
无例外：
| 借口 | 现实 |
|---|---|
| "需求很明确，直接开始" | 需求"明确"≠需求"正确"。误解成本高于设计讨论成本 |
| "先写个原型再说" | 无设计的原型=技术债。重构比从头设计更难 |
| "用户没时间讨论" | 宁可等待也不浪费开发时间。错误实现浪费双方时间 |
| "这很简单不需要设计" | 简单功能也可能有复杂交互。设计5分钟节省调试5小时 |
| "我理解用户意图" | 你理解的≠用户想要的。确认总比假设好 |
所有这些意味着：停止编码。回到设计讨论阶段。
Brainstorming 是一种通过苏格拉底式提问来探索用户意图、明确需求、对比方案的设计方法。
┌─────────────────────────────────────────────────────────┐
│ 理解项目状态 → 逐一提问 → 探索方案 → 分段呈现 → 保存设计 │
└─────────────────────────────────────────────────────────┘
核心原则：
在提问前，先检查：
项目结构
ls -la
find . -name "*.md" -o -name "*.txt" | head -20
现有文档
最近提交
git log --oneline -10
git diff HEAD~1
目标：建立上下文，避免重复提问
提问原则：
一次只问一个问题
优先选择题
探索替代方案
每次 200-300 词，每段后确认：
## 设计文档 - [功能名称]
### 概述
[200-300 词的功能概述]
**这段描述是否正确？**
### 数据模型
[200-300 词的数据模型设计]
**这个数据模型是否满足你的需求？**
### API 设计
[200-300 词的 API 设计]
**这些接口是否足够？还需要其他接口吗？**
### 技术选型
[200-300 词的技术选型说明]
**你同意这个技术栈吗？有其他偏好吗？**
关键点：
在最终确认前，主动提问：
## YAGNI 检查
我注意到设计中包含了以下功能：
- [ ] 功能 A
- [ ] 功能 B
- [ ] 功能 C
**问题**：
1. 功能 A 是否是 MVP 必需？能否延后到 v2.0？
2. 功能 B 是否有真实使用场景？还是"可能有需要"？
3. 功能 C 是否简化了？能否用更简单的方案替代？
**YAGNI 原则**：只实现当前明确需要的功能。
实践要点：
设计确认后，保存到 docs/plans/：
# 创建目录
mkdir -p docs/plans
# 保存设计文档
docs/plans/YYYY-MM-DD--[feature-name]-design.md
文档模板：
# [功能名称] 设计文档
**创建日期**：YYYY-MM-DD
**状态**：已确认 / 待确认
## 概述
[功能概述]
## 需求
[用户需求]
## 方案对比
### 方案 A
- 优势：
- 劣势：
### 方案 B
- 优势：
- 劣势：
**选择方案 A，因为...**
## 数据模型
[数据模型设计]
## API 设计
[API 接口设计]
## 技术选型
[技术栈选择]
## 实现计划
[简要实现步骤]
## YAGNI 移除项
以下功能考虑过但移除：
- 功能 X：原因...
- 功能 Y：原因...
---
**设计者**：AI Agent
**确认者**：用户
在以下场景时激活：
何时不需要使用：
你想要实现什么功能？
A. 用户可以 [具体行为]（推荐）
B. 系统自动 [具体行为]
C. 其他（请说明）
这个功能的主要用户是谁？
A. 终端用户（推荐：关注易用性）
B. 管理员（推荐：关注效率）
C. 开发者（推荐：关注可扩展性）
对于 [功能]，我建议考虑以下方案：
**方案 A：[技术1]**（推荐）
- 优势：[具体优势]
- 劣势：[具体劣势]
**方案 B：[技术2]**
- 优势：[具体优势]
- 劣势：[具体劣势]
你倾向于哪个方案？或者有其他想法？
我注意到设计中包含了 [功能 X]。
**问题**：这个功能是否是 MVP 必需？
A. 是的，必须有（请说明原因）
B. 可以延后到 v2.0（推荐：简化 MVP）
C. 完全不需要（YAGNI：移除）
A: 宁可等待也不浪费开发时间。
回应策略：
我理解时间紧迫。但错误实现浪费的时间远超设计讨论时间。
我建议：
1. 用 5 分钟快速确认核心需求（只问关键问题）
2. 我提供 2-3 个方案供你选择（选择题，快速决策）
3. 确认后立即开始实现
这样可以避免"开发两周后发现方向错误"的情况。
A: "看着办"≠"任意办"。仍需确认核心决策。
回应策略：
我理解你希望我自主决策。但在开始前，我需要确认几个关键点：
1. **核心目标**：这个功能主要解决什么问题？
2. **约束条件**：有时间/技术/资源限制吗？
3. **优先级**：速度优先还是质量优先？
确认这些后，我会提供完整的设计方案供你确认。
A:
节省时间技巧：
设计确认后，检查：
docs/plans/注意：writing-plans 技能需要配合 executing-plans 或 subagent-driven-development 使用。