define-cognitive-brainstorm

Brainstorm — Structured Brainstorming

Entry/Exit

• Entry: vague ideas, open-ended questions, "how do I do X?", choosing one among multiple design options
• Exit: docs/features/YYYYMMDD-<name>/00-brainstorm.md + user-approved direction
• Points to: after user approval, suggest define-workflow-spec(requirements are clear) or define-workflow-refine(still needs convergence)
• Preload: CANON.md
• Output path: docs/features/YYYYMMDD-<name>/00-brainstorm.md → downstream define-workflow-refine or define-workflow-spec

When not to use

• The user has already given a clear spec, acceptance criteria, and execution boundaries
• Just implementing a specific task in an already-approved plan
• The problem requires fact-checking or code diagnosis, not option divergence

Iron Law

脑暴的价值 = 收敛时的明确性 - 发散时的混乱度。
发散是过程，收敛是目的。
"不做清单"可能是最有价值的部分——集中就是放弃好想法。

Agent Dispatch Contract

/brainstorm Useseat-on-demandmulti-seat parallel brainstorming mode.

Phase 1: the current agent directly performs context exploration.

Phase 2: based on --profile or --seats select a scout combination, read commands/brainstorm-menu.json then use the Agent tool to launch in parallel./brainstorm is a Markdown phase protocol, not a shell CLI; parameters are interpreted by the current agent.

Parameters and configuration rules:

• --list-profiles: only list profiles / seats in commands/brainstorm-menu.json , do not launch scouts
• --profile <name>: use task_profiles.<name>.seats
• --seats a,b,c: normalize short names to brainstorm-<name>-scout
• No parameters provided: use default_seats
• brainstorm-outlier-scout is included automatically by default; only if the user explicitly writes --no-outlier is it excluded
• commands/brainstorm-menu.json When missing or unparseable, STOP, switch to the inline profile list in this skill, and mark fallback in the output

Available Scouts:

• agents/brainstorm-tech-scout.md — technical feasibility, architecture options, implementation paths
• agents/brainstorm-design-scout.md — user experience, interaction paths, emotional connection
• agents/brainstorm-business-scout.md — product value, market positioning, business model
• agents/brainstorm-content-scout.md — narrative structure, audience resonance, expression style
• agents/brainstorm-data-scout.md — data modeling, storage strategy, query optimization
• agents/brainstorm-security-scout.md — threat model, protection strategy, compliance requirements
• agents/brainstorm-outlier-scout.md — edge perspectives, radical ideas, reverse thinking (participates by default, the user may explicitly --no-outlier exclude)

Preset Profiles:

• general: tech + design + business + outlier (default)
• tech_architecture: tech + data + security + outlier
• product_strategy: business + design + content + outlier
• content_marketing: content + design + business + outlier
• api_design: tech + data + security + outlier
• security_review: security + tech + data + outlier
• user_experience: design + content + business + outlier
• data_strategy: data + tech + security + outlier

Each scout executes independently without interfering with the others, diverging using its own professional framework. When the host does not support subagents, the current agent simulates them serially by seat and clearly marks fallback; it must not pretend that they were parallel.

Phase 3: the current agent acts as facilitator, performing cross-fertilization and debate:

• Have scouts read each other's reports
• Mark points of contention
• Identify merge opportunities

Phase 4: the current agent converges and integrates, outputting the final recommendation.

• Do not pull agents from other phases (refine/plan/build/review) into the brainstorming phase early.
• If brainstorming finds that the requirements are already clear enough, output the recommended direction and hand off to the subsequent spec/refine process, rather than creating implementation tasks in this phase.

Flow: Diverge → Converge → Polish

Phase 1: Explore Context

Before going deeper:

1. Read the project's AGENTS.md / spec / plan to understand the current state; if Claude-specific guidance is needed, then also read CLAUDE.md
2. Read the relevant code—avoid empty speculation detached from the codebase
3. Clarify constraints: "Technically X already exists, so the solution must not break it"

Phase 2: Multi-perspective parallel divergence

After reading commands/brainstorm-menu.json , use the Agent tool to launch the selected scouts in parallel, each diverging from a different perspective:

Scout framework assignment:

Scout	Core framework	Output
brainstorm-tech-scout	First Principles / Constraints / Pre-mortem / Time-travel	Technical proposals, architecture options, implementation paths, innovation opportunities
brainstorm-design-scout	HMW / Crazy 8 / Role-play / Anti-pattern	Design proposals, user journeys, interaction patterns, emotional design
brainstorm-business-scout	JTBD / Blue Ocean / Business Model Canvas / Pre-mortem	Business proposals, value propositions, market positioning, growth paths
brainstorm-outlier-scout	Inversion / 10x Thinking / Constraints → Freedom / Challenge all assumptions	Radical proposals, reverse thinking, black swan events, cross-domain borrowing

Key points for parallel execution:

• All scouts receive the same context and constraints
• Each scout outputs 2-3 proposals + Wildcards
• outlier-scout by default participates and must propose at least 1 "seemingly absurd" idea; when the user explicitly --no-outlier , the reason for exclusion must be recorded
• Scouts do not interfere with each other and diverge completely independently

Phase 3: Cross-fertilization & debate

Cross-Pollination:

• Have all scouts read each other's reports
• Mark complementary points: tech's innovation + design's experience + business's value
• Mark conflict points: technical feasibility vs user experience vs business value

Debate:

• For disputed points, have the relevant scouts debate
• outlier-scout 's task is to challenge all consensus
• The goal is not to "persuade the other side" but to "expose hidden assumptions"

Synthesis:

• Find solutions that can be merged (the intersection of tech + design + business)
• Find disagreements that require choosing one of two options (clarify the trade-off)
• Identify the combination directions with the most potential

Phase 4: Convergence evaluation

每个方案 vs. 评估标准:
├── 技术可行性: 现有架构能支持吗？
├── 实现成本: 几天？几周？几个月？
├── 用户体验: 用户真的会喜欢吗？还是只是在纸上看起来好？
├── 维护负担: 未来改动的容易度？
├── 风险: 什么可能出错？
└── 增长潜力: 这个方案可扩展吗？

Three convergence steps:

1. Rough screening: Use the Iron Law (clarity of convergence > chaos of divergence) to quickly eliminate options clearly weaker than the others
2. Layered evaluation: Each surviving solution goes through six dimensions → mark strengths / weaknesses / blockers
3. Adopt/Reject: Clearly write out the Adopt reason or Reject reason for each solution (Reject reasons go into the "not-to-do list")

Output 2-3 comparative solutions, not 10+.

Phase 4: Polishing and recommendation

Each solution outputs:

方案 <名称>
├── 核心思想 (1 句)
├── 具体做法 (3-5 步)
├── 优点
├── 缺点
├── 风险 + 缓解
└── 或不推荐 + 理由

Must be given with reasons explained. Brainstorming is not "listing all options for you to choose from." It is "I most recommend X, because Y. Alternative Z, if X's C risk is too high."

Key behaviors

Surface Assumptions

List assumptions before each solution. Hidden assumptions are the most common killer in planning.

Push Back

Don't be a yes-man. If a solution has clear problems—say so and quantify the impact. Honesty > flattery.

Focus

A "not-to-do list" is as important as a "to-do list." Abandoning 3 out of 5 solutions = concentrating force.

Brainstorming output template

Template starting point:templates/feature/00-brainstorm.md

# 设计: [主题]

## 背景
[为什么现在做、什么约束、谁需要这个]

## 假设
[列出要验证的关键假设]

## 决策标准
- 必须满足:
- 优先优化:
- 可以牺牲:
- 明确不能:

## 关键假设验证
| 假设 | 风险 | 验证方式 | 通过标准 |
|------|------|----------|----------|
| <假设> | 高/中/低 | <如何验证> | <什么结果算通过> |

## 方案

### 方案 A: [名称]
- 做法:
- 优点:
- 缺点:
- 风险:
- 推荐: [是/否] 因为...

### 方案 B: [名称]
...

## 推荐
**选择方案 X** 因为: [理由]
备选方案 Y 如果: [什么条件下备选变成首选]

## 不做
- [放弃的方向 + 原因]
- [放弃的方向 + 原因]

## 开放问题
[需要用户输入才能继续的]

## 下一阶段交接
- 推荐进入: `/refine` / `define-workflow-spec`
- 已锁定决策:
- 下游必须继续验证:
- 不允许下游重新打开:

Common talking points

Talking point	Reality	Consequence
"The solution obviously doesn't need brainstorming"	Spending 10 more minutes listing the "not-doing list" and hidden assumptions is far more valuable than skipping it.	Skipping brainstorming and implementing directly, 3 days later you find the direction is wrong, and the rework cost is 50-100x that of 10 minutes of brainstorming.
"This is too simple to need design"	"This is one line of code" truly doesn't need design. "This is a button" needs execution position, state, label, a11y.	Simple assumptions lead to missed edge cases, which erupt as bugs after launch.
"List all options for you to choose from"	This is giving up judgment. You are a technical partner—give a and reasons.	10 options with no recommendation = the user cannot decide, the discussion stalls, and all participants' time is wasted.
"Option X is perfect"	There is no perfect option. Every option has drawbacks—not stating the drawbacks = not thought through.	Hidden drawbacks are exposed during implementation, and only during rework do you discover the root cause lies in the option choice, with a 10x fix cost.

Red flags — STOP

• Number of options > 5 (diverged without converging—converge first, then recommend)
• Starting design without writing down assumptions
• Fantasy divorced from the codebase (sounds spectacular but is technically impossible)
• The not-doing list is empty (accommodating all ideas too much = no trade-offs made)
• No recommendation given—only "A is good, B is good, C is good" (no judgment)
• The user explicitly stated a constraint but the option ignores it (brainstorming that doesn't listen = wasting time)

Verification checklist

• Relevant code and CLAUDE.md have been read
• Assumptions have been listed
• Decision criteria have been listed
• Key assumptions have verification methods and pass criteria
• 2-3 clearly compared options
• Each option has pros, cons, risks
• Clear recommendation + reasons
• The "not-doing list" has content
• Next-phase handoff is clearly written
• Enter the spec phase after the user has approved the direction

Verification failure handling

Failure scenario	Handling method
Number of options after divergence > 5	Converge first, then recommend. Merge similar options, delete options clearly weaker than the others. Output 2-3.
"Not-doing list" is empty after convergence	Mandatorily require listing at least 2 abandoned directions + reasons. The not-doing list is as important as the doing list.
User constraints are ignored by the options	Mark as Blocking, return to Phase 1 to re-understand the constraints.
All options have high risk	Honestly inform the human partner, recommend "don't do it" or "reduce risk first, then decide." Do not recommend high-risk options.
Unable to give a clear recommendation	List the blocking issues for the recommendation, and ask the human partner to decide. Do not end the brainstorm with "either is fine."

Good and bad examples

Good — structured brainstorming

# 设计: 用户通知系统

## 假设
- 用户日活 > 10k，通知量级需要考虑
- 已有 WebSocket 基础设施

## 方案

### 方案 A: 实时推送（推荐）
- 做法: WebSocket + 消息队列 + 前端 toast
- 优点: 即时性强，用户体验好
- 缺点: 连接管理复杂，服务器成本高
- 风险: WebSocket 断连时需 fallback → 缓解: 30s 轮询兜底

### 方案 B: 轮询 + 缓存
- 做法: 前端每 30s 请求未读计数 API
- 优点: 实现简单，服务器成本低
- 缺点: 延迟 30s，高并发时 API 压力大
- 风险: 用户错过时效性通知

## 推荐: 方案 A — 即时性对通知系统是核心价值
备选 B: 如果 WebSocket 基础设施不成熟

## 不做
- 邮件通知（当前阶段 scope 外）
- SMS 通知（成本过高，ROI 不匹配）

Bad — brainstorming without convergence

# 设计: 用户通知系统

## 方案
方案 A: WebSocket
方案 B: 长轮询
方案 C: SSE
方案 D: 邮件
方案 E: 推送通知
方案 F: 短轮询
（没有假设、没有评估标准、没有推荐、不做清单为空）

-> 问题: 方案 > 5 个，发散未收敛（红旗 #1）
-> 问题: 没有假设就开始设计方案（红旗 #2）
-> 问题: 不做清单为空 = 没做取舍（红旗 #5）
-> 问题: 没有推荐 = 放弃判断（红旗 #6，常见说辞"列出所有选项给你选"）