---
name: brainstorming
description: 当用户要探索、比较、挑战或补全开发方案时使用；通过一次一个问题和可见置信度形成可安全实施的共同设计，并可在用户选择持久化后维护 OpenSpec Living brainstorm。
license: MIT
metadata:
  author: "devkeel"
  version: "8.0.3"
---

# 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 显示“实施准备度”，衡量共同上下文能否安全生成 Apply 所需 artifacts。

置信度按 5% 取值，表示当前阶段的证据充分程度，不是成功概率、工作完成比例或用户授权。
先按本阶段最关键的未闭合缺口选择下表分档，再按仓库事实与已确认决定取值；档内依据不足时取
较低值。不得按对话轮数、D/O 条数或已确认决定数量加分，也不得把 90% 当作“尚未完成”的默认值。

| 分档 | 边界置信度（topic-only） | 实施准备度（change-draft） |
|------|------------------------|--------------------------|
| 0–55% | 目标或主要范围尚不清楚 | 主方案尚未形成，或核心可行性存在冲突 |
| 60–75% | 目标已知，主要范围或职责仍待决定 | 主方案已有方向，但核心链路或必需外部能力尚未证实 |
| 80–85% | 主要范围与职责明确，仍有影响边界的决定 | 核心可行性有依据，主要契约、恢复或验证方案仍未闭合 |
| 90% | 主要边界与持久化价值已判明，仅剩影响有限的局部确认 | 主要方案与契约已闭环，仅剩影响有限的局部决定 |
| 95% | 当前边界问题已闭合，可判断下一路径 | 无阻塞 O-*，目标、边界、行为、方案与验证闭环，可确认快照 |

分档必须满足本阶段对应条件；更低档的关键缺口不能被其他已确认事项抵消。证据足以支持方案选择
即可，不要求提前完成实现或全部联调；已明确留待实施后执行的验证不自动成为当前阻塞项。但未知
能力若可能推翻主方案，仍按核心可行性缺口处理，不能仅记作“后续联调”后给高分。

切换阶段时重新评估，禁止直接沿用上一阶段数值；单独展示新阶段分数和依据，不把两个指标写成
同一条涨跌轨迹。范围扩大、新增依赖或假设被推翻时，重估受影响的缺口；原分档不再满足时降档。
同阶段仅在新证据或决定改变评估依据时调分，可保持或下降，不为显示进展强制上升。

每轮说明本轮闭合项、支持当前分档的事实、最大未决项及其对下一步的阻塞性；分数不变时也要说明
本轮进展与限制升档的缺口，不能只报“维持 90%”。没有新闭合项或阻塞项时如实说明。不输出评分
矩阵，数值不单独决定推进。存在会改变结构、可观察行为或维护方式的开放决定时，实施准备度
不得达到 95%；100% 仅在用户确认完整快照后使用，不用于 topic-only。

推荐的紧凑表达：

```text
实施准备度：75%（不变）
进展：已确认页面关闭后停止查询，后台任务独立执行。
评估：任务职责已有依据，但目标版本是否支持持久化任务仍未证实，限制升档且阻塞快照确认。
下一步：核对目标版本的任务能力。
```

## 事实与探针

先查项目约束、代码、配置、测试和相关 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

边界置信度达到约 80%，且存在跨会话恢复、交接、并行协作或审计等真实持久化价值时，显式提醒
用户是否建立 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. 按实施准备度分档重新评估并显示分数，不继承边界置信度；继续询问唯一的下一项 gap。

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

## 快照确认

实施准备度达到 95%、没有阻塞 O-*、且 Agent 能说明目标、边界、行为、方案与验证如何闭环时：

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

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

5. 将实施准备度视为 100%，下游尚未生成时保持 `NONE`；随后把控制权交给 Continue/FF。

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

## 旧 change 的延迟迁移

旧 `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，不把“讨论完成”表述为“实现完成”。