brainstorming v9.0.0A

Immutable. This exact content is served forever at /api/v1/blob/24797d5d173f8c3a.

---
name: brainstorming
description: 当用户要探索、比较、挑战或补全开发方案时使用；通过单题访谈、阶段与关键缺口提示形成共同设计，并可在用户选择持久化后维护 OpenSpec Living brainstorm。
license: MIT
metadata:
  author: "devkeel"
  version: "9.0.0"
---

# Brainstorming

通过对话逐项补齐开发者心中的上下文。目标不是尽量少问，而是每轮只解决一个决定，让用户能看见
理解如何收敛；同一 change 只允许这一处进行需求与技术设计，后续 artifacts 只能投影。

## 两种工作状态

### topic-only（默认）

在聊天上下文中调查和讨论，不创建 change，不写文件。适用于大多数尚在探索、尚不确定是否值得
持久化的主题，也适用于已有完整方案的 Gap Check。

### change-draft

仅在用户显式调用 `/opsx:new`，或 Agent 说明持久化价值并得到用户同意后进入。创建 DevKeel
change 后，在 `brainstorm.md` 中维护同一份 Living Artifact；它仍是共同设计过程，不是生成后的
长文审批。

进入 change-draft 不授权修改实现代码、生成下游 artifact 或 Apply。用户显式调用 `/opsx:ff`
只改变推进节奏，不允许跳过未确认决定。

## 输入成熟度与讨论阶段

先区分用户目标、仓库事实、外部未知和输入成熟度：

- 早期想法：从方向探索开始；
- 已有方案：只找高影响缺口，不重新设计；
- 目标、方案、验收都明确：紧凑核验，必要时可直接达到快照门槛；
- 用户明确要求 brainstorm/grill：即使输入成熟也保持显式互动。

按当前工作状态的关键缺口判断讨论阶段：

| 阶段 | 条件 |
|------|------|
| 探索中 | 目标、范围或主方向仍有关键不确定性，或核心可行性缺少依据 |
| 收敛中 | 主方向已有依据，仍需补齐影响边界、行为、方案或验证的决定 |
| 可确认 | 当前讨论目标已闭合，没有阻塞开放项，可以总结并请用户确认 |

topic-only 的闭合范围是目标、主要边界与下一路径；change-draft 还须满足下文“快照确认”的
条件。阶段不代表用户授权；用户明确确认后记录确认状态，不再评分。

每轮只用一行“阶段 · 关键缺口”说明位置与剩余决定；没有缺口时写“无，待确认当前结论”。
仅在阶段或关键缺口变化时展开解释，说明新证据、已闭合项或新增阻塞；不重复评估，不估算百分比
或剩余轮数，也不按已确认决定数量推进阶段。例如：

```text
收敛中 · 关键缺口：任务失败后的恢复方式尚未确定。
```

切换工作状态、范围扩大、新增依赖或假设被推翻时，按受影响的缺口重新判断阶段，不沿用旧结论。
证据足以支持方案选择即可；已明确留待实施后执行的验证不自动成为阻塞项。但可能推翻主方案的
未知能力仍是核心可行性缺口，不能仅记作“后续联调”。

## 事实与探针

先查项目约束、代码、配置、测试和相关 artifacts，不把仓库可查事实反问用户。只加载必要范围；
热上下文仍可靠时复用，外部编辑、压缩或关键事实缺失时才刷新。

按需使用 `requirement-analysis` 与 `technical-design` 的探针模式：

- 需求探针发现目标、范围、可观察行为、验收和外部约束缺口；
- 技术探针发现结构、契约、状态、失败恢复、迁移和维护边界缺口；
- 两者只返回候选 gap，不写报告、不替用户作决定；
- 合并并去重 gap 后，仅选择 `影响 × 不确定性` 最高的一项作为下一题。

它们是 Brainstorming 的问题发现器，不是 artifact 生成器。进入下游投影阶段后禁止自动调用这些
skill；若投影发现缺口，退出投影并回到这里。

## 单题访谈循环

每轮严格只处理一个决定：

1. 简述已知事实和为什么此项现在最关键；
2. 提出一个问题；
3. 给出 Agent 的推荐答案、推荐依据和主要代价；存在多个合理选项时，紧凑列出选项并明确标注
   推荐项，让用户可以直接确认、选择或纠正；
4. 等待回答，不预先提出依赖于该答案的下一题；
5. 回答无歧义时更新决定、阶段与关键缺口；有歧义时继续澄清同一件事，不得持久化成决定。

问题可以简单且次数可以多。不得一次倾倒问题清单、长篇设计或语义差异报告。答案推翻旧理解时，
重新判断阶段并排列 gap。

## 决定模型

- `D-*`：用户明确确认的语义决定；一项只表达一件事。
- `A-*`：用户明确交给 Agent 自主决定的类别，不是 Agent 私自补出的设计。
- `O-*`：仍待回答的阻塞问题；`CONFIRMED` 时必须为 0。
- 仓库事实：直接引用可定位的代码、测试、配置或文档，不伪装成 D/A。

topic-only 在当前对话维护这些编号。进入 change-draft 时，将当前有效 D/A/O 原样映射进
`brainstorm.md`；不重新分析、不改写含义、不补“最佳实践”。顶部概要和主题分组只是阅读视图。
正文引用决定时使用可点击的 Markdown 链接，如 `[D-03](#d-03)`；跨 artifact 使用
`[D-03](brainstorm.md#d-03)`。标题使用纯 `#### D-03`，不插入 HTML anchor。

答案确认后，change-draft 可在同一轮写入对应 D/A，并把已解决 O 移除或移入变更记录。任何语义
变化都把状态重置为 `DRAFT`、下游状态改为 `STALE`（尚无下游则 `NONE`）；纯排版和链接修复不
改变确认状态。

## topic-only → change-draft

目标、主要范围与职责已明确，且存在跨会话恢复、交接、并行协作或审计等真实持久化价值时，显式提醒
用户是否建立 OpenSpec change。没有这些价值时继续 topic-only 或 Direct，不为使用 OpenSpec
制造文档。

用户同意后：

1. 加载并遵循 `openspec-new-change` 创建 Lite（显式/已确认 Full 除外）；
2. 使用其动态 `resolvedOutputPath` 初始化最小 `brainstorm.md`；
3. 把当前有效 D/A/O 忠实迁入，状态为 `DRAFT`，不重新提问已确认事项；
4. 运行本 skill 的 `scripts/planning-state.mjs` 检查结构；
5. 按 change-draft 的缺口重新判断阶段；有 gap 时只问下一项，已闭合时进入快照确认。

映射完成后的正常回执只需说明迁入数量和来源，例如“已从本轮对话迁入 6 D / 1 A / 1 O”；
不要要求用户通读完整 Markdown。

## 快照确认

没有阻塞 O-*，不存在会改变结构、可观察行为或维护方式的开放决定，且 Agent 能说明目标、边界、
行为、方案与验证如何闭环时，进入“可确认”：

1. 列出所有当前有效 D-* 与 A-*，每项保持一句话；
2. 说明准备投影的下游 artifacts 与主要验证方式；
3. 只询问用户是否确认这份完整快照，不夹带新的设计问题；
4. 用户明确确认后，将状态行改为：

   ```text
   > **状态：** `CONFIRMED` · **确认项：** 18 D / 3 A / 0 O
   ```

5. 下游尚未生成时保持 `NONE`；随后把控制权交给 Continue/FF。

用户修正任一项时仍为 `DRAFT`，写回对应决定并继续单题循环。缺失、重复、计数不一致、存在 O-*、
或状态行无效都不是 Confirmed。

## 旧 change 的延迟迁移

旧 DRAFT 状态行若使用百分比，检查器仍识别为 `DRAFT` 并返回 `needsStageMigration: true`。
下一次维护该 brainstorm 时，按实际缺口重评阶段，将状态行改为 `DRAFT` · `阶段` 格式；不得从
旧分数直接映射阶段，不改变 D/A/O 或下游状态，不批量改写旧文件。

旧 `brainstorm.md` 没有 Living 状态行时，不默认它已确认。第一次 Continue/Update/Apply：

1. 从现有 planning artifacts 提取可追溯的 D/A/O 候选，保留当前下游文件；
2. 向用户展示完整精简快照，并一次确认或修正；
3. 确认后改写为 Living Artifact；若下游忠实覆盖快照则标为 `CURRENT`，否则标为 `STALE`；
4. 只有新增、冲突或遗漏语义才要求重投影，不做批量迁移。

## 停止边界

- topic-only：输出当前决定、开放项、阶段提示和下一步；不写文件。
- change-draft：只维护 `brainstorm.md`；不生成 design/specs/tasks。
- 快照已确认：交给 OpenSpec 投影入口；本 skill 不自行生成下游 artifacts 或实现。
- 用户暂停：保留当前 D/A/O 与下一 gap，不把“讨论完成”表述为“实现完成”。