brainstorming · diff
v8.0.3 to v9.0.0
31 added, 42 removed. Audit A to A.
---
name: brainstorming
- description: 当用户要探索、比较、挑战或补全开发方案时使用；通过一次一个问题和可见置信度形成可安全实施的共同设计，并可在用户选择持久化后维护 OpenSpec Living brainstorm。
+ description: 当用户要探索、比较、挑战或补全开发方案时使用；通过单题访谈、阶段与关键缺口提示形成共同设计，并可在用户选择持久化后维护 OpenSpec Living brainstorm。
license: MIT
metadata:
author: "devkeel"
- version: "8.0.3"
+ 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 显示“实施准备度”，衡量共同上下文能否安全生成 Apply 所需 artifacts。
-
- 置信度按 5% 取值，表示当前阶段的证据充分程度，不是成功概率、工作完成比例或用户授权。
- 先按本阶段最关键的未闭合缺口选择下表分档，再按仓库事实与已确认决定取值；档内依据不足时取
- 较低值。不得按对话轮数、D/O 条数或已确认决定数量加分，也不得把 90% 当作“尚未完成”的默认值。
-
- | 分档 | 边界置信度（topic-only） | 实施准备度（change-draft） |
- |------|------------------------|--------------------------|
- | 0–55% | 目标或主要范围尚不清楚 | 主方案尚未形成，或核心可行性存在冲突 |
- | 60–75% | 目标已知，主要范围或职责仍待决定 | 主方案已有方向，但核心链路或必需外部能力尚未证实 |
- | 80–85% | 主要范围与职责明确，仍有影响边界的决定 | 核心可行性有依据，主要契约、恢复或验证方案仍未闭合 |
- | 90% | 主要边界与持久化价值已判明，仅剩影响有限的局部确认 | 主要方案与契约已闭环，仅剩影响有限的局部决定 |
- | 95% | 当前边界问题已闭合，可判断下一路径 | 无阻塞 O-*，目标、边界、行为、方案与验证闭环，可确认快照 |
-
- 分档必须满足本阶段对应条件；更低档的关键缺口不能被其他已确认事项抵消。证据足以支持方案选择
- 即可，不要求提前完成实现或全部联调；已明确留待实施后执行的验证不自动成为当前阻塞项。但未知
- 能力若可能推翻主方案，仍按核心可行性缺口处理，不能仅记作“后续联调”后给高分。
+ 按当前工作状态的关键缺口判断讨论阶段：
- 切换阶段时重新评估，禁止直接沿用上一阶段数值；单独展示新阶段分数和依据，不把两个指标写成
- 同一条涨跌轨迹。范围扩大、新增依赖或假设被推翻时，重估受影响的缺口；原分档不再满足时降档。
- 同阶段仅在新证据或决定改变评估依据时调分，可保持或下降，不为显示进展强制上升。
+ | 阶段 | 条件 |
+ |------|------|
+ | 探索中 | 目标、范围或主方向仍有关键不确定性，或核心可行性缺少依据 |
+ | 收敛中 | 主方向已有依据，仍需补齐影响边界、行为、方案或验证的决定 |
+ | 可确认 | 当前讨论目标已闭合，没有阻塞开放项，可以总结并请用户确认 |
- 每轮说明本轮闭合项、支持当前分档的事实、最大未决项及其对下一步的阻塞性；分数不变时也要说明
- 本轮进展与限制升档的缺口，不能只报“维持 90%”。没有新闭合项或阻塞项时如实说明。不输出评分
- 矩阵，数值不单独决定推进。存在会改变结构、可观察行为或维护方式的开放决定时，实施准备度
- 不得达到 95%；100% 仅在用户确认完整快照后使用，不用于 topic-only。
+ topic-only 的闭合范围是目标、主要边界与下一路径；change-draft 还须满足下文“快照确认”的
+ 条件。阶段不代表用户授权；用户明确确认后记录确认状态，不再评分。
- 推荐的紧凑表达：
+ 每轮只用一行“阶段 · 关键缺口”说明位置与剩余决定；没有缺口时写“无，待确认当前结论”。
+ 仅在阶段或关键缺口变化时展开解释，说明新证据、已闭合项或新增阻塞；不重复评估，不估算百分比
+ 或剩余轮数，也不按已确认决定数量推进阶段。例如：
```text
- 实施准备度：75%（不变）
- 进展：已确认页面关闭后停止查询，后台任务独立执行。
- 评估：任务职责已有依据，但目标版本是否支持持久化任务仍未证实，限制升档且阻塞快照确认。
- 下一步：核对目标版本的任务能力。
+ 收敛中 · 关键缺口：任务失败后的恢复方式尚未确定。
```
+ 切换工作状态、范围扩大、新增依赖或假设被推翻时，按受影响的缺口重新判断阶段，不沿用旧结论。
+ 证据足以支持方案选择即可；已明确留待实施后执行的验证不自动成为阻塞项。但可能推翻主方案的
+ 未知能力仍是核心可行性缺口，不能仅记作“后续联调”。
+
## 事实与探针
先查项目约束、代码、配置、测试和相关 artifacts，不把仓库可查事实反问用户。只加载必要范围；
热上下文仍可靠时复用，外部编辑、压缩或关键事实缺失时才刷新。
按需使用 `requirement-analysis` 与 `technical-design` 的探针模式：
- 需求探针发现目标、范围、可观察行为、验收和外部约束缺口；
- 技术探针发现结构、契约、状态、失败恢复、迁移和维护边界缺口；
- 两者只返回候选 gap，不写报告、不替用户作决定；
- 合并并去重 gap 后，仅选择 `影响 × 不确定性` 最高的一项作为下一题。
它们是 Brainstorming 的问题发现器，不是 artifact 生成器。进入下游投影阶段后禁止自动调用这些
skill；若投影发现缺口，退出投影并回到这里。
## 单题访谈循环
每轮严格只处理一个决定：
1. 简述已知事实和为什么此项现在最关键；
2. 提出一个问题；
3. 给出 Agent 的推荐答案、推荐依据和主要代价；存在多个合理选项时，紧凑列出选项并明确标注
推荐项，让用户可以直接确认、选择或纠正；
4. 等待回答，不预先提出依赖于该答案的下一题；
- 5. 回答无歧义时更新决定、置信度与推进评估；有歧义时继续澄清同一件事，不得持久化成决定。
+ 5. 回答无歧义时更新决定、阶段与关键缺口；有歧义时继续澄清同一件事，不得持久化成决定。
问题可以简单且次数可以多。不得一次倾倒问题清单、长篇设计或语义差异报告。答案推翻旧理解时，
- 按前述分档重估置信度并重新排列 gap。
+ 重新判断阶段并排列 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。
+ 5. 按 change-draft 的缺口重新判断阶段；有 gap 时只问下一项，已闭合时进入快照确认。
映射完成后的正常回执只需说明迁入数量和来源，例如“已从本轮对话迁入 6 D / 1 A / 1 O”；
不要要求用户通读完整 Markdown。
## 快照确认
- 实施准备度达到 95%、没有阻塞 O-*、且 Agent 能说明目标、边界、行为、方案与验证如何闭环时：
+ 没有阻塞 O-*，不存在会改变结构、可观察行为或维护方式的开放决定，且 Agent 能说明目标、边界、
+ 行为、方案与验证如何闭环时，进入“可确认”：
1. 列出所有当前有效 D-* 与 A-*，每项保持一句话；
2. 说明准备投影的下游 artifacts 与主要验证方式；
3. 只询问用户是否确认这份完整快照，不夹带新的设计问题；
4. 用户明确确认后，将状态行改为：
```text
> **状态：** `CONFIRMED` · **确认项：** 18 D / 3 A / 0 O
```
- 5. 将实施准备度视为 100%，下游尚未生成时保持 `NONE`；随后把控制权交给 Continue/FF。
+ 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：输出当前决定、开放项、置信度、推进评估和下一步；不写文件。
+ - topic-only：输出当前决定、开放项、阶段提示和下一步；不写文件。
- change-draft：只维护 `brainstorm.md`；不生成 design/specs/tasks。
- 快照已确认：交给 OpenSpec 投影入口；本 skill 不自行生成下游 artifacts 或实现。
- 用户暂停：保留当前 D/A/O 与下一 gap，不把“讨论完成”表述为“实现完成”。