Brainstorming

Skill huangwb8/skills/awesome-code/agents/brainstorming

General Skills Development Pipeline - Claude Code & Codex

Install

npx -y skills add huangwb8/skills --skill brainstorming

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

What its author says it does

Copied from the file, not written here

当用户明确要求"使用 brainstorming"或"使用 awesome-code"时使用。⚠️ 不适用：用户只是想优化/改进某个功能（应直接修改）、只是询问技能问题（应直接回答）、没有明确使用 brainstorming/awesome-code 的一般性开发。

SKILL.md

11.1 KB, as published. Nobody here has run it

Brainstorming - 交互式设计优化

BenszAPI 任务工作区

本 Skill 的新任务中间文件统一写入 ./.bensz-api/task-{yyyymmdd-hhmm}-{简短描述}/{skill名}/input|output|log/。同一任务复用一个任务根目录；多 Skill 协作才创建 shared/。正式交付物不写入该目录，历史隐藏目录只允许显式兼容读取、迁移或清理。

与 bensz-collect-bugs 的协作约定

因本 skill 设计缺陷导致的 bug，先用 bensz-collect-bugs 规范记录到 ~/.bensz-skills/bugs/，不要直接修改用户本地已安装的 skill 源码；若有 workaround，先记 bug，再继续完成任务。
只有用户明确要求“report bensz skills bugs”等公开上报时，才用本地 gh 上传新增 bug 到 huangwb8/bensz-bugs；不要 pull / clone 整个仓库。

铁律

NO IMPLEMENTATION WITHOUT DESIGN DISCUSSION FIRST

违反规则的信件就是违反规则的精神。

无例外：

不跳过设计阶段直接编码
不基于模糊需求直接实现
不在用户确认前开始编码
YAGNI（You Aren't Gonna Need It）无情移除非必要功能

常见合理化

借口	现实
"需求很明确，直接开始"	需求"明确"≠需求"正确"。误解成本高于设计讨论成本
"先写个原型再说"	无设计的原型=技术债。重构比从头设计更难
"用户没时间讨论"	宁可等待也不浪费开发时间。错误实现浪费双方时间
"这很简单不需要设计"	简单功能也可能有复杂交互。设计5分钟节省调试5小时
"我理解用户意图"	你理解的≠用户想要的。确认总比假设好

红色标志 - 停止并重新开始

"需求很明确，直接开始"
"先写个原型再说"
"用户没时间讨论"
"这很简单不需要设计"
"我理解用户意图"
跳过设计讨论直接编码

所有这些意味着：停止编码。回到设计讨论阶段。

核心原则

Brainstorming 是一种通过苏格拉底式提问来探索用户意图、明确需求、对比方案的设计方法。

┌─────────────────────────────────────────────────────────┐
│  理解项目状态 → 逐一提问 → 探索方案 → 分段呈现 → 保存设计  │
└─────────────────────────────────────────────────────────┘

核心原则：

一次一个问题：不要用多个问题压倒用户
多选题优先：选择题比开放式问题更容易回答
探索替代方案：在确定前总是提出 2-3 个方案
增量验证：分段展示设计，逐段确认
YAGNI 无情：从所有设计中移除非必要功能

自主模式

当用户明确要求“不要反复确认”“自己选最优方案”“直接推进”时，不要把提问流程机械执行成阻塞。

此时改为 静默设计简报：

先在内部补齐 purpose / audience / constraints / options / chosen direction / assumptions
用 2-3 个候选方向做快速比较，但只把最终选定方向和关键取舍写给用户
设计阶段仍然必须先于实现，只是“讨论”改为内部完成、对外输出结论
如果已有项目或设计系统足够清晰，直接基于现有上下文收敛方案，不为了提问而提问

工作流程

步骤 1：理解项目状态

在提问或静默设计前，先检查：

项目结构

ls -la
find . -name "*.md" -o -name "*.txt" | head -20

现有文档
- README.md 是否存在？
- 是否有 docs/ 目录？
- 是否有设计文档？
最近提交
```
git log --oneline -10
git diff HEAD~1
```

目标：建立上下文，避免重复提问

步骤 2：逐一提问

提问原则：

一次只问一个问题
- ❌ 坏："你需要什么功能？用什么技术栈？什么时候完成？"
- ✅ 好："你想要实现什么功能？"
优先选择题
- ❌ 坏："你需要什么类型的用户认证？"
- ✅ 好："用户认证你希望用哪一种？"
  - A. JWT Token（推荐：无状态、跨平台）
  - B. Session Cookie（简单：传统 Web 应用）
  - C. OAuth 第三方登录（社交登录场景）
  - D. 其他（请说明）
探索替代方案
- ❌ 坏："好的，我们用 JWT 实现。"
- ✅ 好："对于用户认证，我建议考虑以下方案："
  - 方案 A：JWT Token（推荐）
    - 优势：无状态、跨平台、移动端友好
    - 劣势：需要管理过期和刷新
  - 方案 B：Session Cookie
    - 优势：简单、服务器控制
    - 劣势：有状态、不适合微服务
  - 方案 C：无认证（如果适用）
    - 优势：最简单
    - 劣势：无安全控制
  - 推荐方案 A，因为你的项目需要支持移动端。

步骤 3：分段呈现设计

每次 200-300 词，每段后确认：

## 设计文档 - [功能名称]

### 概述

[200-300 词的功能概述]

**这段描述是否正确？**

### 数据模型

[200-300 词的数据模型设计]

**这个数据模型是否满足你的需求？**

### API 设计

[200-300 词的 API 设计]

**这些接口是否足够？还需要其他接口吗？**

### 技术选型

[200-300 词的技术选型说明]

**你同意这个技术栈吗？有其他偏好吗？**

关键点：

✅ 每段后等待用户确认
✅ 用粗体标记问题
✅ 提供具体示例
❌ 不一次性呈现完整设计

步骤 4：YAGNI 无情移除

在最终确认前，主动提问：

## YAGNI 检查

我注意到设计中包含了以下功能：
- [ ] 功能 A
- [ ] 功能 B
- [ ] 功能 C

**问题**：
1. 功能 A 是否是 MVP 必需？能否延后到 v2.0？
2. 功能 B 是否有真实使用场景？还是"可能有需要"？
3. 功能 C 是否简化了？能否用更简单的方案替代？

**YAGNI 原则**：只实现当前明确需要的功能。

实践要点：

✅ 主动质疑每个功能
✅ 提供"延后实现"选项
✅ 推荐最简单可行方案
❌ 不保留"可能有需要"的功能

步骤 5：保存设计文档

设计确认后，保存到 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
**确认者**：用户

何时使用本技能

在以下场景时激活：

🎨 创建新功能：任何新功能开发前
🔧 修改现有行为：改变功能行为前
🏗️ 构建新组件：UI/架构组件设计前
📋 添加功能：任何代码编写前
🤔 需求不明确：用户需求模糊时

何时不需要使用：

❌ 修复 Bug（使用 systematic-debugging）
❌ 重构代码（已有设计，只需优化）
❌ 简单重命名（ trivial 变更）
❌ 文档更新（非功能性变更）

提问模板库

功能需求提问

你想要实现什么功能？

A. 用户可以 [具体行为]（推荐）
B. 系统自动 [具体行为]
C. 其他（请说明）

这个功能的主要用户是谁？
A. 终端用户（推荐：关注易用性）
B. 管理员（推荐：关注效率）
C. 开发者（推荐：关注可扩展性）

技术选型提问

对于 [功能]，我建议考虑以下方案：

**方案 A：[技术1]**（推荐）
- 优势：[具体优势]
- 劣势：[具体劣势]

**方案 B：[技术2]**
- 优势：[具体优势]
- 劣势：[具体劣势]

你倾向于哪个方案？或者有其他想法？

YAGNI 检查提问

我注意到设计中包含了 [功能 X]。

**问题**：这个功能是否是 MVP 必需？
A. 是的，必须有（请说明原因）
B. 可以延后到 v2.0（推荐：简化 MVP）
C. 完全不需要（YAGNI：移除）

常见问题

Q1: 用户说"没时间讨论"怎么办？

A: 宁可等待也不浪费开发时间。

回应策略：

我理解时间紧迫。但错误实现浪费的时间远超设计讨论时间。

我建议：
1. 用 5 分钟快速确认核心需求（只问关键问题）
2. 我提供 2-3 个方案供你选择（选择题，快速决策）
3. 确认后立即开始实现

这样可以避免"开发两周后发现方向错误"的情况。

Q2: 用户说"你看着办"怎么办？

A: "看着办"≠"任意办"。仍需确认核心决策。