brainstorming

name	brainstorming
description	在创造性开发前使用——一次确认完整需求、方向和全部 Stage，再交给 grill-with-docs 依次完成各 Stage 设计

将想法转化为完整需求

通过协作讨论，将想法转化为明确的需求边界、方向选型和 Stage 划分。一次 brainstorming 必须覆盖整项需求及全部 Stage；后续不会在 Stage 之间重新讨论需求。

开始时声明： “我正在使用 brainstorming 技能探索完整需求和方向。”

在完整需求、方向选型和全部 Stage 获得用户确认前，不得调用 grill-with-docs、writing-plans 或任何实现技能。

何时不使用

• 修复已知 bug：使用 systematic-debugging
• 审查已有代码：使用 code-review
• 用户明确指定不采用本流程：按用户指定方式处理

流程

digraph brainstorming {
    "探索项目上下文" [shape=box];
    "评估整体复杂度" [shape=box];
    "需要多个 Stage？" [shape=diamond];
    "划分全部 Stage" [shape=box];
    "探索完整需求" [shape=box];
    "提出 2-3 种方向" [shape=box];
    "确认需求、方向和全部 Stage" [shape=box];
    "用户确认？" [shape=diamond];
    "保存 brainstorming 索引" [shape=box];
    "调用 grill-with-docs" [shape=doublecircle];

    "探索项目上下文" -> "评估整体复杂度";
    "评估整体复杂度" -> "需要多个 Stage？";
    "需要多个 Stage？" -> "划分全部 Stage" [label="是"];
    "需要多个 Stage？" -> "探索完整需求" [label="否"];
    "划分全部 Stage" -> "探索完整需求";
    "探索完整需求" -> "提出 2-3 种方向";
    "提出 2-3 种方向" -> "确认需求、方向和全部 Stage";
    "确认需求、方向和全部 Stage" -> "用户确认？";
    "用户确认？" -> "探索完整需求" [label="需要修改"];
    "用户确认？" -> "保存 brainstorming 索引" [label="已确认"];
    "保存 brainstorming 索引" -> "调用 grill-with-docs";
}

过程

1. 探索项目上下文

先检查：

• 项目结构和主要入口
• 与需求有关的现有实现和测试
• docs/CONTEXT.md 或 docs/CONTEXT-MAP.md
• docs/adr/ 中已有决策
• 最近提交和当前工作区状态

能通过代码和文档确认的事实不向用户重复询问。

2. 评估并划分 Stage

需求包含多个里程碑或规模过大时，划分为多个严格串行的 Stage。划分依据是实现依赖和文档规模，不是中间版本的发布能力。

Stage 不表示：

• 可部署版本
• 服务正常运行的中间版本
• 需要长期维护的兼容边界
• 需要重新进入 brainstorming 的独立需求

Stage 只用于：

• 控制设计和计划文档规模
• 表达实现先后依赖
• 形成执行时的 Git 合并检查点

无须拆分时，将整项需求视为一个隐式 Stage。

3. 探索完整需求

沿设计树自顶向下确认：

• 目标和使用场景
• 做什么与不做什么
• 最终成功标准
• 技术和业务约束
• 全部 Stage 的范围、依赖和顺序

优先使用选择题。每次解决一个上层决策，再讨论依赖它的下层决策。

4. 提出方向

提出 2-3 种不同方向，说明：

• 最终结构差异
• 主要权衡
• 与现有代码模式的匹配程度
• 推荐方向及理由

方向选型只决定采用哪种整体方案。接口、错误处理、数据流和测试细节交给 grill-with-docs。

5. 确认完整需求

展示并确认：

• 完整需求边界
• 最终成功标准
• 选定方向
• 全部 Stage 的范围
• Stage 间依赖和执行顺序
• 明确排除的内容

确认只发生一次。不得只确认第一个 Stage 后进入设计。

产出

保存到：

docs/brainstorming/YYYY-MM-DD-<slug>.md

slug 使用 kebab-case 英文，并由所有后续文档沿用。

文档至少包含：

# <功能名称> 需求与方向

## 需求边界

## 最终成功标准

## 方向选型

## 明确排除

## Stage 索引

### Stage 1：<名称>

- 范围：<该 Stage 负责的最终能力>
- 依赖：无
- 设计状态：未完成
- 计划状态：未完成
- 执行状态：未完成
- 设计文件：尚未生成
- 计划文件：尚未生成

### Stage 2：<名称>

- 范围：<该 Stage 负责的最终能力>
- 依赖：Stage 1
- 设计状态：未完成
- 计划状态：未完成
- 执行状态：未完成
- 设计文件：尚未生成
- 计划文件：尚未生成

无显式 Stage 时仍保留一个 Stage 条目，便于后续 skill 使用统一结构。

状态维护

• grill-with-docs 完成一个 Stage 后，更新对应设计状态和设计文件。
• writing-plans 完成一个 Stage 后，更新对应计划状态和计划文件。
• smart-exec-plan 完成并审查一个 Stage 后，更新对应执行状态。
• 状态更新与对应产物或代码一起提交，不生成纯状态提交。

终止条件

满足以下条件后调用 grill-with-docs：

1. 完整需求已确认。
2. 最终成功标准已确认。
3. 方向选型已确认。
4. 全部 Stage 的范围、依赖和顺序已确认。
5. brainstorming 索引已保存。

brainstorming 不在 Stage 之间重新启动。