brainstorming · diff
v9.0.0 to v9.1.0
69 added, 120 removed. Audit A to A.
---
name: brainstorming
- description: 当用户要探索、比较、挑战或补全开发方案时使用；通过单题访谈、阶段与关键缺口提示形成共同设计，并可在用户选择持久化后维护 OpenSpec Living brainstorm。
+ description: 探索、比较、挑战或补全开发方案；按 Lite/Full 深度进行单题访谈，并在用户同意持久化后维护 OpenSpec Living brainstorm。
license: MIT
metadata:
author: "devkeel"
- version: "9.0.0"
+ version: "9.1.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：即使输入成熟也保持显式互动。
+ 通过单题访谈形成共同设计。同一 change 的需求与技术设计只在此处发生，下游 artifacts 只投影。
- 按当前工作状态的关键缺口判断讨论阶段：
+ ## 工作状态与权限
- | 阶段 | 条件 |
+ | 状态 | 边界 |
|------|------|
- | 探索中 | 目标、范围或主方向仍有关键不确定性，或核心可行性缺少依据 |
- | 收敛中 | 主方向已有依据，仍需补齐影响边界、行为、方案或验证的决定 |
- | 可确认 | 当前讨论目标已闭合，没有阻塞开放项，可以总结并请用户确认 |
-
- topic-only 的闭合范围是目标、主要边界与下一路径；change-draft 还须满足下文“快照确认”的
- 条件。阶段不代表用户授权；用户明确确认后记录确认状态，不再评分。
-
- 每轮只用一行“阶段 · 关键缺口”说明位置与剩余决定；没有缺口时写“无，待确认当前结论”。
- 仅在阶段或关键缺口变化时展开解释，说明新证据、已闭合项或新增阻塞；不重复评估，不估算百分比
- 或剩余轮数，也不按已确认决定数量推进阶段。例如：
-
- ```text
- 收敛中 · 关键缺口：任务失败后的恢复方式尚未确定。
- ```
-
- 切换工作状态、范围扩大、新增依赖或假设被推翻时，按受影响的缺口重新判断阶段，不沿用旧结论。
- 证据足以支持方案选择即可；已明确留待实施后执行的验证不自动成为阻塞项。但可能推翻主方案的
- 未知能力仍是核心可行性缺口，不能仅记作“后续联调”。
+ | topic-only（默认） | 在会话中调查、讨论或做 Gap Check，不创建 change、不写文件；结束时输出决定、开放项、阶段与下一步 |
+ | change-draft | 用户显式 `/opsx:new` 或同意持久化后进入，只维护 `brainstorm.md` |
- ## 事实与探针
+ 本 skill 不修改实现、不生成下游 artifacts；`/opsx:ff` 只改变节奏，不跳过未确认决定。
+ 用户暂停时保留 D/A/O 与下一 gap，不把讨论完成表述为实现完成。
- 先查项目约束、代码、配置、测试和相关 artifacts，不把仓库可查事实反问用户。只加载必要范围；
- 热上下文仍可靠时复用，外部编辑、压缩或关键事实缺失时才刷新。
+ ## 按需引用
- 按需使用 `requirement-analysis` 与 `technical-design` 的探针模式：
+ 普通 topic-only 无 change 线索且无需查询时，不加载以下引用：
- - 需求探针发现目标、范围、可观察行为、验收和外部约束缺口；
- - 技术探针发现结构、契约、状态、失败恢复、迁移和维护边界缺口；
- - 两者只返回候选 gap，不写报告、不替用户作决定；
- - 合并并去重 gap 后，仅选择 `影响 × 不确定性` 最高的一项作为下一题。
+ - 定位、读取或恢复已有 change 状态（含冲突或复用查询）：先读 [OpenSpec 上下文](references/openspec-context.md)。
+ - 准备创建、恢复持久化讨论、维护、确认或迁移 Living brainstorm：先读 [Living brainstorm](references/living-brainstorm.md)。
- 它们是 Brainstorming 的问题发现器，不是 artifact 生成器。进入下游投影阶段后禁止自动调用这些
- skill；若投影发现缺口，退出投影并回到这里。
+ 仅查看 change 不授权写入；已有可靠上下文可复用，不因加载引用重复查询。
- ## 单题访谈循环
+ ## 讨论深度
- 每轮严格只处理一个决定：
+ 深度 `lite` / `full` 控制探索范围，与工作流 schema、工作状态分别维护；切换深度不改变它们或
+ 文档、实施、治理授权。
- 1. 简述已知事实和为什么此项现在最关键；
- 2. 提出一个问题；
- 3. 给出 Agent 的推荐答案、推荐依据和主要代价；存在多个合理选项时，紧凑列出选项并明确标注
- 推荐项，让用户可以直接确认、选择或纠正；
- 4. 等待回答，不预先提出依赖于该答案的下一题；
- 5. 回答无歧义时更新决定、阶段与关键缺口；有歧义时继续澄清同一件事，不得持久化成决定。
+ 选择优先级：用户当前明确指定 → 当前主题已记录深度 → 已选工作流的同名默认值。均无时，明确要求
+ 探索方向、比较方案或挑战思路用 Full，其余（包括已有方案）用 Lite。支持自然语言覆盖；仅在歧义
+ 明显影响讨论范围时询问。首次进入或深度变化时简述深度与依据。
- 问题可以简单且次数可以多。不得一次倾倒问题清单、长篇设计或语义差异报告。答案推翻旧理解时，
- 重新判断阶段并排列 gap。
+ | 深度 | 探索与探针策略 | 收敛要求 |
+ |------|----------------|----------|
+ | Lite | 围绕当前方向补缺，按需定向调用需求或技术探针 | 当前讨论目标闭合，没有阻塞决定 |
+ | Full | 主动检查相关假设、替代方向与风险，完成需求和技术双探针检查 | 满足 Lite 条件，且两类检查已完成或有有效结果可复用 |
- ## 决定模型
+ 两档都须处理影响主方案或关键验收的风险，不按问题数、调用次数或篇幅衡量深度，不遍历无关维度、
+ 制造问题或替代方案。Full 达到条件即收敛，无须先降为 Lite。
- - `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`）；纯排版和链接修复不
- 改变确认状态。
+ 先区分用户目标、仓库事实和外部未知，查必要的约束、代码、配置、测试与 artifacts，不反问可查
+ 事实。可靠热上下文直接复用，外部编辑、压缩或关键事实缺失时刷新。
- ## topic-only → change-draft
+ 早期想法先探索方向；已有方案按当前深度核验，不重新生成设计；成熟输入复用依据，检查完成即可
+ 收敛。用户明确要求 brainstorm/grill 时，即使输入成熟也保持显式互动。
- 目标、主要范围与职责已明确，且存在跨会话恢复、交接、并行协作或审计等真实持久化价值时，显式提醒
- 用户是否建立 OpenSpec change。没有这些价值时继续 topic-only 或 Direct，不为使用 OpenSpec
- 制造文档。
+ 调用 `requirement-analysis` / `technical-design` 的 probe 模式时，传入深度、目标与边界、已有
+ D/A、仓库依据及探查重点，专业维度由探针负责。目标不清时先探需求，方向有依据后再深入技术。
- 用户同意后：
+ 复用探查须有可追溯结论，目标、边界、依据仍适用，且覆盖当前深度所需检查。Lite → Full 只复用
+ 已覆盖部分，补齐尚未检查的相关假设、替代方向与风险；不每轮重跑，不以“已调用”认定完成。
- 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 时只问下一项，已闭合时进入快照确认。
+ 探针只返回候选问题、依据与影响，不写报告、不替用户决定；无缺口时返回检查结论。合并去重后，
+ 影响当前方向成立或关键验收的未知作为阻塞项，额外机会作为可选建议，不自动扩大范围或进入 O-*。
+ 已有决定只因新证据揭示冲突或风险才重开。
- 映射完成后的正常回执只需说明迁入数量和来源，例如“已从本轮对话迁入 6 D / 1 A / 1 O”；
- 不要要求用户通读完整 Markdown。
+ 下游投影阶段禁止调用这些探针；发现缺口时退出投影，回到 Brainstorming。
- ## 快照确认
+ ## 阶段与单题访谈
- 没有阻塞 O-*，不存在会改变结构、可观察行为或维护方式的开放决定，且 Agent 能说明目标、边界、
- 行为、方案与验证如何闭环时，进入“可确认”：
+ | 阶段 | 条件 |
+ |------|------|
+ | 探索中 | 目标、范围、主方向仍不明确，或核心可行性缺少依据 |
+ | 收敛中 | 主方向有依据，仍有影响边界、行为、方案或验证的决定 |
+ | 可确认 | 当前讨论目标闭合、无阻塞项，且当前深度检查完成 |
- 1. 列出所有当前有效 D-* 与 A-*，每项保持一句话；
- 2. 说明准备投影的下游 artifacts 与主要验证方式；
- 3. 只询问用户是否确认这份完整快照，不夹带新的设计问题；
- 4. 用户明确确认后，将状态行改为：
+ topic-only 的闭合范围是目标、主要边界与下一路径；change-draft 还须满足
+ [完整快照确认](references/living-brainstorm.md#快照确认)。
+ 阶段不代表用户授权；确认后记录确认状态，不再评分。
- ```text
- > **状态：** `CONFIRMED` · **确认项：** 18 D / 3 A / 0 O
- ```
+ 每轮用一行“阶段 · 关键缺口”提示；无缺口时写“无，待确认当前结论”。仅在阶段或关键缺口变化时
+ 展开新证据、闭合项或新增阻塞。不重复评估，不按百分比、剩余轮数或决定数量衡量进展。
- 5. 下游尚未生成时保持 `NONE`；随后把控制权交给 Continue/FF。
+ 切换工作状态、范围扩大、新增依赖或假设被推翻时，按受影响缺口重评，不沿用旧结论。证据足以支持
+ 选择即可：留待实施后执行的验证不自动成为阻塞项；可能推翻主方案的未知能力仍是核心可行性缺口，
+ 不得留作“后续联调”。
- 用户修正任一项时仍为 `DRAFT`，写回对应决定并继续单题循环。缺失、重复、计数不一致、存在 O-*、
- 或状态行无效都不是 Confirmed。
+ 每轮严格只处理一个决定，选择 `影响 × 不确定性` 最高的阻塞项：
- ## 旧 change 的延迟迁移
+ 1. 说明事实与重要性，提出一个问题，给出推荐答案、依据与主要代价；多个合理选项时紧凑列出并明确标注推荐项。
+ 2. 等待回答，不预问依赖问题；有歧义只澄清当前项，不持久化猜测。
+ 3. 无歧义则更新决定、阶段与关键缺口；答案推翻旧理解时重新排序 gap。
- 旧 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. 只有新增、冲突或遗漏语义才要求重投影，不做批量迁移。
+ - `D-*`：用户明确确认的单项语义决定。
+ - `A-*`：用户明确授权 Agent 自主决定的类别，不得自行补造。
+ - `O-*`：阻塞问题，`CONFIRMED` 时必须为 0。
+ - 仓库事实：引用可定位依据，不伪装成 D/A。
- ## 停止边界
+ topic-only 在会话中保留编号、深度与来源。目标、主要范围与职责已明确，且有跨会话恢复、交接、并行
+ 或审计价值时，询问是否建立 change；否则继续 topic-only 或 Direct。
- - topic-only：输出当前决定、开放项、阶段提示和下一步；不写文件。
- - change-draft：只维护 `brainstorm.md`；不生成 design/specs/tasks。
- - 快照已确认：交给 OpenSpec 投影入口；本 skill 不自行生成下游 artifacts 或实现。
- - 用户暂停：保留当前 D/A/O 与下一 gap，不把“讨论完成”表述为“实现完成”。
+ 持久化设计须经用户明确确认完整 D/A 快照后才可交给下游入口；阶段或文件存在不代表确认。
+ 设计语义变化须重新确认，未确认或已失效的内容不得投影；具体记录、快照与恢复步骤见上述引用。