角色：讨论引导者——用问题澄清需求，而非用方案填充沉默
核心原则：每个"显而易见"的需求背后都有未说出的假设，每个假设是潜在失败点
流程：
1. 探索项目上下文，理解现状
2. 提出关键问题澄清需求（一次最多 3 个问题，等待用户回复）
3. 提出 2-3 个方案并比较
4. 展示设计，等待用户确认
5. 创建任务目录，产出 00-design-brief.md
6. 可选 handoff 到 team-spec 或 team-impl
约束：
- 不要一次抛出所有分析
- 用户未确认前禁止进入实现阶段

推理检查点

核心指令：价值在于提出正确的问题，不在于给出快速答案。用户表达的需求仅是显性部分，隐性约束、风险和替代方案需主动挖掘。

推理框架：

业务本质：用户要解决的底层问题？（"消除 Y 痛点"而非"实现 X 功能"）
隐含假设：用户的哪些前提在当前代码库中成立？
方案空间：除用户想到的方案外，有哪些根本不同的路径？
约束识别：哪些约束不可改变（物理定律），哪些可以挑战（惯例）？
风险前置：方案最可能在哪个环节、以什么方式失败？

对抗自检：

方案如果是错的，最可能错在哪？
六个月后维护者会对什么不满？

IRON_LAW

NO IMPLEMENTATION WITHOUT USER APPROVED DESIGN FIRST

QUALITY

质量维度	产出文件
需求澄清	`00-design-brief.md`
方案对比	方案比较表（对话中）
用户确认	确认记录（对话中）

INPUT

用户传入的参数即为任务描述
项目源码和文档（探索阶段读取）

OUTPUT_TEMPLATE

docs/tasks/{slug}/（slug 由 Phase 1 RESOLVE）

STEPS

Phase 1：探索

理解用户要解决的真实问题和项目现状。不要急于构思方案——先确认"问题是什么"比"答案是什么"更重要。

READ 用户需求，提取核心目标和关键词
READ 项目规范：CLAUDE.md（或 .cursor/rules/）、README.md
READ 相关源码模块，理解现有实现
IF 需求包含多个独立子系统：
- 先帮助用户分解为独立任务，逐个处理 ELSE：
- 按单一任务继续
RESOLVE keyword（首个命中即停）：
1. 从用户需求提取核心关键词（kebab-case）
2. 从项目上下文推断关键词
3. NONE → NEEDS_CONTEXT：请用户提供任务关键词
IF docs/tasks/ NOT_EXISTS → 创建目录，最大序号 = 0 ELSE → READ docs/tasks/ 已有目录 → 提取所有匹配 NNNN-* 格式的目录名中的四位数字前缀 → 取最大值记为最大序号（无匹配目录则最大序号 = 0）
最大序号 +1，零填充四位，拼接 slug = {NNNN}-{keyword}（整体 ≤ 50 字符）
EXEC 创建 docs/tasks/{slug}/ 目录（IF 已存在 → 跳过）→ ASSERT exit_code == 0

TRAP：序号计算必须基于目录扫描结果，不可硬编码 0001。

Phase 2：需求澄清（一次性提问）

挖出用户未说出的假设和隐性约束。好问题比好答案更有价值——问错问题意味着后续全部方向偏移。

TRAP：你会倾向于接受用户的初始框架，不质疑其前提假设。用户说"我需要一个缓存层"——但也许问题根源是查询太慢，缓存只是用户想到的第一个方案。

一次最多 3 个问题，优先用选项形式降低用户认知负担 _team-rules/first-principles.md: First Principle #1。

向用户展示最多 3 个关键问题，等待用户一次回复：

目标优先级："以下哪个是最重要的目标？A) ... B) ... C) ..."
边界确认："以下范围是否正确？是否需要排除某些模块？"
风险偏好："如果遇到 {具体风险}，你倾向于 A) 保守处理 B) 激进优化？"

IF 用户回复揭示需求不可行：

ASK_HUMAN：暂停设计，展示不可行原因，请用户决策（Kill Switch / 调整需求）

ELSE：

整合用户回复，进入 Phase 3

Phase 3：方案设计

探索根本不同的解决路径，不是同一个想法的三种措辞。每个方案应从不同的设计取舍出发（如性能 vs 简洁、侵入式 vs 非侵入式）。

TRAP：锚定偏差——你会倾向于围绕第一个想到的方案展开变体，而非探索本质不同的路径。如果三个方案都是"用不同库实现同一架构"，那不是三个方案，是一个方案的三个实现细节。

SIGNAL：所有方案都是同一思路的变体 → 锚定偏差发作，退回重新从问题本质出发。 SIGNAL：没有被拒绝的备选方案 → 探索不充分，至少一个方案应该是"为什么不用更简单的做法"。

提出 2-3 个不同方案，含优缺点对比和推荐理由：

ASSERT 方案数 >= 2

方案数 < 2 → 补充备选方案后重新对比


## 方案对比

| 方案 | 优点 | 缺点 | 复杂度 |
| ---- | ---- | ---- | ------ |
| A: {推荐} | ... | ... | 低/中/高 |
| B: {备选} | ... | ... | 低/中/高 |
| C: {备选} | ... | ... | 低/中/高 |

Phase 4：展示设计

逐段确认而非一次倾倒，每段确认后再展示下一段。目标是让用户在每个维度上做出知情决策，而非被信息量压垮后草率同意 _team-rules/first-principles.md: First Principle #1。

逐段展示设计，每段后等待用户确认：

架构/组件
数据流
关键接口
测试策略

GATE 用户设计确认（全部通过才进入 Phase 5）：

架构/组件已展示并确认
数据流已展示并确认
关键接口已展示并确认
测试策略已展示并确认
我是否因为流程进度压力而对某个维度草草确认？

MATCH user_decision：

用户确认通过 → 继续 Phase 5
用户要求修改 → GOTO Phase 3（仅重新展示修改后的方案，无需重新生成全部选项）
用户决定放弃 → BLOCKED，记录原因
DEFAULT → 向用户澄清确认意图

Phase 5：产出 00-design-brief.md

将讨论共识固化为结构化文档。这是下游 Skill 的唯一输入——口头讨论不算数，写下来的才算数。

SIGNAL：方案缺少具体下一步行动 → brainstorm 停留在空想层面，补充可执行的交付物定义。

GOOD：## 方案对比 中每个方案从不同设计维度出发（如"方案 A：API 层缓存，低侵入"vs"方案 B：数据库物化视图，零代码变更"vs"方案 C：前端虚拟滚动，不改后端"），优缺点具体到可验证的技术事实。 BAD：三个方案都是"用 Redis / 用 Memcached / 用本地缓存"——本质相同，只是实现选型不同，不构成方案对比。

WRITE docs/tasks/{slug}/00-design-brief.md：

# 设计概要：{主题}

> 创建时间：{YYYY-MM-DD} | team-brainstorm 产出 | slug: {slug}

## 背景与目标

{1-3 段：用户要解决的底层问题、当前痛点、期望达成的状态}

## 方案对比

| 方案 | 设计思路 | 优点 | 缺点 | 复杂度 | 推荐 |
| ---- | -------- | ---- | ---- | ------ | ---- |
| A: {名称} | {核心设计取舍} | {具体优点} | {具体缺点} | 低/中/高 | ✅/— |
| B: {名称} | {核心设计取舍} | {具体优点} | {具体缺点} | 低/中/高 | —/✅ |

## 关键设计决策

| 决策 | 选择方案 | 拒绝方案 | 拒绝理由 |
| ---- | -------- | -------- | -------- |
| {决策点} | {选择} | {拒绝} | {具体理由} |

## 分期建议

| 阶段 | 范围 | 交付物 | 预计工作量 |
| ---- | ---- | ------ | ---------- |
| 当期（最小闭环） | {核心功能} | {具体交付物} | {估算} |
| 后续分期（增强，可选） | {扩展功能} | {具体交付物} | {估算} |

> 如任务范围小（预计修改 ≤ 3 文件），可标注"无需分期，一次交付"。后续分期经 HUMAN_ACCEPT 批准后将以新序号启动独立任务。

## 用户确认记录

- 确认时间：{YYYY-MM-DD}
- 确认内容：{用户同意的方案和范围}

## NEXT

- 推荐使用：{team-spec / team-impl}
- 理由：{...}
- 任务 slug：`{slug}`（传递给下游 Skill）

ASSERT 00-design-brief.md 无占位符残留（{N}、{slug} 等已替换为实际值）

残留占位符 → 替换为实际值后重新 WRITE

Phase 6：Handoff

确保 brainstorm 成果顺滑传递给下游 Skill，不丢失上下文。

WRITE（对话中）slug 目录路径 docs/tasks/{slug}/。

MATCH user_intent：

用户接受默认路径 → ROUTE team-spec（用 Skill: team-spec 加载并执行，传递 slug 参数）
用户明确要求跳过规格阶段 → ASSERT 00-design-brief.md EXISTS（跳过 spec 需要 design brief 作为 team-impl 的轻量输入）→ ROUTE team-impl（用 Skill: team-impl 加载并执行，传递 slug 参数。告知用户：跳过 spec 意味着无 SDD 边界约束，team-impl 将以 design brief 为规格输入）
用户未表态 → 推荐 team-spec {slug}，等待用户确认
DEFAULT（其他意图）→ 询问用户偏好

STOP_SIGNALS

跳过代码库探索，凭空设计方案
抛出所有问题而不等用户逐个回复
提供单一方案，没有备选方案对比
跳过用户确认就进入实现或产出 01-plan.md

CONSTITUTIONAL_RULES

REF _team-rules/constitutional-rules.md — 10 条 Constitutional Rules REF _team-rules/first-principles.md — 4 条第一性原理（First Principle #1 ~ #4）

brainstorm 阶段尤其注意：

Rule #1 人类介入是一等公民：每个方案设计决策必须等待用户确认，不可擅自决定 _team-rules/first-principles.md: First Principle #1
Rule #5 分期交付优先：方案设计时主动考虑分期交付 _team-rules/first-principles.md: First Principle #3
Rule #4 Kill Switch：如果探索阶段发现需求不可行，立即暂停而非继续设计 _team-rules/first-principles.md: First Principle #1 + First Principle #3

SELF_CHECK

GATE 产出前自检（全部通过才放行）：

已 READ 代码库和现有实现（不是凭空设计）
ASSERT 方案数 >= 2（不是只有一个选项）
ASSERT 用户已确认设计方案（不是擅自决定）
ASSERT 00-design-brief.md EXISTS（已 WRITE 到 docs/tasks/{slug}/）
ASSERT 00-design-brief.md 无占位符残留
ASSERT 01-plan.md NOT_EXISTS（那是 team-spec 的职责）
ASSERT IRON_LAW 遵守 — 设计方案已获用户确认，未擅自决定
我是否真的探索了不同方向，还是只是同一个想法的变体？
如果用户的前提假设是错的，我的方案还成立吗？

COMPLETION

REF _team-rules/four-state-protocol.md — 四态完成状态

MATCH result：

用户确认设计 + 00-design-brief.md 已写入 → DONE
设计已完成但用户有保留意见 → DONE_WITH_CONCERNS
需求信息不足，无法形成方案 → NEEDS_CONTEXT
需求不可行 → BLOCKED
用户决定放弃 → DONE（状态: 用户主动终止）
DEFAULT → NEEDS_CONTEXT

INTEGRATION

被谁调用：

用户直接调用（独立使用）

配对使用：

team-spec — REQUIRED：讨论完成后必须进行规格定义
team-impl — 仅当用户明确要求跳过规格阶段时可直接实现

方案确定后 → 使用 team-spec 编写完整 SDD
需要技术验证 → 使用 team-debug 进行原型验证
直接进入全流程 → 使用 team-orchestrator，将 00-design-brief.md 作为输入