在 OpenSpec 项目中用探索模式理清需求与方案（只思考…

当用户想在 OpenSpec 变更之前或过程中先想清楚问题、调研代码、澄清需求时，进入探索模式做思考伙伴。

适用场景

解决思路

1. 进入探索模式：深入思考、自由画图、跟随对话走向，不设固定步骤、必需顺序或强制产出。
2. 明确探索模式只用于思考不用于实现：可以读文件、搜代码、调研代码库、运行只读命令或工具而无需确认，但绝不写代码或实现功能；用户要求实现时，说明探索模式不实现，并指向 `/openspec-propose`。
3. 可以在已确认范围内创建或更新 OpenSpec 变更产物（proposal、design、spec），这属于记录思考而非实现；回答设计或澄清问题绝不等于同意写入。
4. 在第一个具备写入能力的动作之前，先说明将要改动的产物或文件及具体做法，提出直接的 yes/no 问题，并在另一条消息中等待用户确认；确认只覆盖所描述的范围，扩大范围前需再次询问。
5. 用户明确要求把探索记录为新变更时，该请求本身即为确认，覆盖该变更及请求中命名的变更产物；先按下方流程脚手架化该变更。
6. 选择 store：若用户指定 store 或工作位于某个 store 中，运行 `openspec store list --json` 发现已注册的 store id，然后在读写 specs 和 changes 的命令（`new change`、`status`、`instructions`、`list`、`show`、`validate`、`archive`、`doctor`、`context`、`schemas`、`view`）上追加 `--store <id>`；选定后在整个工作流中保持粘性，后续命令示例都视为省略了该标志，例如运行 `openspec status --change "<name>" --json --store "<id>"`；其他命令不接受该标志；命令打印的提示已带该标志，后续跟进也要保留；没有 store 时命令作用于最近的本地 `openspec/` 根目录。
7. 项目检查：在第一个写入动作（`new change`、`archive`、`sync specs` 或编写产物文件）之前，运行 `openspec list --json`（选定 store 时加 `--store <id>`，此时 store 即根目录）并读取 `root`；有 root 对象说明项目已配置；`"root": null` 说明未配置，此处没有 `openspec/` 目录，写入如 `openspec new change` 会作为副作用创建它，且命令以非零退出码返回，这是答案而非 CLI 故障，应读取 JSON 而不是重试或绕过。
8. 处理 `"root": null` 的例外：当 `status` 错误消息以 `Declared in` 或 `Invalid store declaration in` 开头并指向本项目的 `openspec/config.yaml`（或 `config.yml`）时，说明项目通过其声明的 store 使用 OpenSpec，但本机无法解析（store 未注册或 `store:` 行格式错误）；不要当作未初始化而跳过后续分支，应在写入前停止并向用户展示该错误的 `message` 和 `fix`。
9. 无 root 时按到达方式分支：若是自动选择（你自己选了此工作流，用户未提及 OpenSpec、未指定此技能、未运行其斜杠命令），停止使用 OpenSpec，按未安装 OpenSpec 的方式正常回答请求，不要要求用户做任何设置，也不要提及 OpenSpec 设置。
10. 无 root 时若是用户显式请求 OpenSpec（用户提及 OpenSpec、指定此技能或运行其斜杠命令），在写入前停止并询问如何继续：用 `openspec init` 设置本项目、指向已有 store（`--store <id>`）、或本次请求不使用 OpenSpec；等待用户回答。
11. 两种分支中都绝不把创建根目录作为副作用：用户未要求前不运行 `openspec init`，不手工创建 `openspec/` 文件，也不让命令创建它。
12. 保持探索姿态：好奇而非规定性，问题自然涌现而不照脚本；打开多条线索而非审问，呈现多个有趣方向让用户跟随，不把用户引入单一问题路径；多用 ASCII 图帮助澄清思考；自适应地跟随有趣线索、在新信息出现时转向；有耐心，不急于下结论，让问题形态自然浮现；脚踏实地，相关时探索真实代码库而不只是空想。
13. 规划变更时用聚焦的发现性问题引导用户达成共识；开放式讨论则跟随对话，不强加访谈或必需产出。
14. 提问事实性问题前先做上下文发现，检查相关 OpenSpec 产物、源码、测试、文档和配置；不要让用户重复你能验证的事实；总结相关发现时不要复述私有上下文或规则；若证据缺失、冲突或不可访问，说明该限制并只询问继续所需澄清。
15. 跟随依赖关系：先解决下一个阻塞性决策再处理其依赖细节，例如先澄清用户的结果和范围再选择 API 或数据模型；早期答案变化时重新审视下游假设；跳过与本目标无关的分支。
16. 保持问题聚焦：一次问一个聚焦问题，并简要说明为何重要、解锁哪个决策；仅在用户要求批量时批量提问，且保持小规模并归组相关决策。
17. 提供有依据的建议：证据支持时说明首选方案及为何契合用户目标，必要时给出替代方案及其权衡；不要臆造意图、优先级或外部约束，只有用户能回答时就问用户；避免固定问题格式。
18. 保持对话式记录：在对话中跟踪决策而非写入文件；区分已确认决策、提议的默认值和未决问题；沉默不等于接受；接受一个答案或一批建议不等于允许写入；把文件写入确认与发现性问题分开，并遵守下方护栏。
19. 用户足够清晰时停止提问，允许他们暂停、转向或推迟决策；不要穷尽每个分支或强推提案。
20. 按用户带来的内容选择动作：探索问题空间（提出澄清问题、挑战假设、重构问题、寻找类比）；调研代码库（梳理相关现有架构、找集成点、识别已有模式、暴露隐藏复杂度）；比较选项（头脑风暴多种方案、做对比表、勾勒权衡、被要求时推荐路径）；可视化（系统图、状态机、数据流、架构草图、依赖图、对比表）；暴露风险与未知（识别可能出错之处、发现理解缺口、建议 spike 或调研）。
21. 画图只用纯 ASCII：边框 `+` `-` `|`，箭头 `-->` `<--` `^` `v`，标记 `*` `x`；Unicode 图形字符在不同终端、字体和语言环境下宽度不同，会导致填充框和对齐表格错位，所有图形字符保持 ASCII。
22. 检查上下文：开始时运行 `openspec list --json` 查看进行中的变更（名称、schema、状态）；再运行 `openspec list --specs` 列出项目持久能力（加 `--json` 获取 id 和需求数量，仅对已注册的独立 store 追加 `--store "<id>"`），`openspec list` 本身从不显示这些。
23. 查看单个 spec：运行 `openspec show "<spec-id>" --type spec --json --no-scenarios`（同样的 `--store` 规则）获取该能力的目的和需求文本而不把整个 spec 文件拉入上下文，`--type spec` 可避免同名变更造成歧义；这只是概览，在判断已覆盖内容或应改内容前，用 `openspec show "<spec-id>" --type spec` 完整读取每个相关 spec（含场景）。
24. 读取项目自身上下文：从解析出的根目录读取 `<root.path>/openspec/config.yaml`（或 `config.yml`），两个文件都不存在则跳过；`context` 是项目背景（技术栈、约定、约束），`rules` 按产物 id 分组，某产物的条目仅在你写该产物时适用；以这些为思考依据，它们是你要遵守的约束而非要复述的内容，不要复制到对话或任何创建的产物中。
25. 无变更时自由思考，洞察成形后可提议："这足够扎实可以开始变更了，要我创建 proposal 吗？"或继续探索，不强制形式化。
26. 用户要求把探索记录为新变更时，该请求即为所需确认，只覆盖脚手架化该变更及创建请求中命名的变更产物；仅当请求来自用户时成立，对你自己提议的 yes 只确认提议本身命名的范围，因此提议中要写明变更和产物；不要重复询问用户已要求的内容，超出范围前要询问；无缝转入捕获流程。
27. 捕获第 1 步：在创建任何产物前运行 `openspec new change "<name>"`（适用时加 `--store <id>`）；绝不手工在 `openspec/changes/` 下创建新变更目录，CLI 脚手架会创建 `.openspec.yaml` 等必需元数据；在每个适用的后续 `status` 和 `instructions` 命令上保留选定的 `--store <id>`。
28. 捕获第 2 步：运行 `openspec status --change "<name>" --json`（仅对已注册的独立 store 追加已确认的 `--store "<id>"`），然后按依赖顺序处理请求的产物；对每个 `ready` 的请求产物运行 `openspec instructions "<artifact-id>" --change "<name>" --json`（同样的 `--store` 规则）；创建请求产物前，针对已探索的变更评估其自身 `instruction` 中的条件，条件不适用时记录为有意跳过。
29. 捕获第 2 步续：若请求的产物被用户未请求的直接前置产物阻塞，对该前置产物运行 `openspec instructions "<prerequisite-id>" --change "<name>" --json`（同样的 `--store` 规则），无论它是 `ready` 还是 `blocked`；若其自身 `instruction` 声明条件，针对已探索的变更评估该条件，仅当条件不适用时记录为有意跳过；若条件适用或该前置产物非条件性，视为正常前置产物并在扩大捕获范围前询问；未经用户批准不要创建未请求的前置产物。
30. 捕获第 3 步：遵循返回的 `template` 和 `instruction` 字段；读取 `dependencies` 中列出的已完成依赖文件；把 `context` 和 `rules` 作为约束应用而不复制进产物；若 instruction 委托给特定技能或命令则调用它，否则把产物写入 `resolvedOutputPath`，当它是 glob 时用 instruction 选择具体路径；验证所选具体输出存在。
31. 捕获第 4 步：每创建一个产物后重新运行 `openspec status --change "<name>" --json`（仅对已注册的独立 store 追加已确认的 `--store "<id>"`），继续直到每个请求产物为 `done`、`skipped`，或因自身 `instruction` 条件不适用而被有意跳过；告知用户有意的条件性跳过、记住它且不再重新考虑。
32. 捕获第 4 步续：依赖是使能者而非门禁；若请求的产物仅因你有意跳过了条件性前置产物而仍为 `blocked`，仍运行 `openspec instructions "<artifact-id>" --change "<name>" --json`（同样的 `--store` 规则），仅当这些记录的条件性跳过是其唯一缺失依赖时按第 3 步创建它；若请求的产物被用户未要求捕获且无法条件性跳过的前置产物阻塞，解释该依赖并在扩大捕获范围前询问。
33. 捕获用户请求的产物，不要让用户再调用另一个工作流命令；若用户只要求启动变更，脚手架化后停止并展示其状态；请求的捕获完成后停止，并指明工作继续的位置：`/openspec-propose` 编写剩余规划产物，`/openspec-apply-change` 在任务存在后实现变更；捕获产物绝不开始实现它们。
34. 存在变更时：运行 `openspec status --change "<name>" --json`，使用其中的 `changeRoot`、`artifactPaths` 和 `actionContext`，从 `artifactPaths.<artifact>.existingOutputPaths` 读取已有文件。
35. 在对话中自然引用已有产物，例如"你的设计提到用 Redis，但我们刚意识到 SQLite 更合适……"或"proposal 把范围限定为高级用户，但我们现在想面向所有人……"。
36. 决策形成时提议捕获：`<capability-path>` 是相对 `specs/` 的 spec 目录（如 `user-auth` 或 `identity/user-auth`），保留已有能力的完整路径，新能力遵循项目既有组织方式；新需求发现或需求变更写入 `specs/<capability-path>/spec.md`，设计决策写入 `design.md`，范围变更写入 `proposal.md`，新工作识别写入 `tasks.md`，假设失效写入相关产物；示例提议如"这是个设计决策，记到 design.md 吗？""这是新需求，加到 specs 吗？""这改变了范围，更新 proposal 吗？"。
37. 由用户决定：提议后继续，不施压、不自动捕获。
38. 不必做的事：照脚本走、每次问同样的问题、产出特定产物、得出结论、有价值的题外话也坚持不离题、保持简短（这是思考时间）。
39. 处理不同入口：用户带来模糊想法时（如实时协作），画出协作光谱（Presence/Cursors/CRDT 从 trivial 到 complex）并问"你的想法在哪？"；用户带来具体问题时（如认证系统混乱），读代码库后画出当前认证流程（Google/GitHub/Email 到 Session 到 Perms）并指出几处纠缠问"哪个最急？"；用户卡在实现中途时（如 `/openspec-explore add-auth-system` 且 OAuth 集成比预期复杂），读变更产物、指出当前任务、画图探索选项并建议路径，问是否更新设计或加 spike 任务；用户想比较选项时（如 Postgres vs SQLite），先问上下文，再按约束（无守护进程、离线、单用户）画对比表并给出结论，同时追问是否有同步组件。
40. 结束发现：没有必需结尾，可能流入 proposal（"准备好就开始？运行 `/openspec-propose` 把它变成变更"）、导致产物更新（"已把这些决策更新到 design.md"）、仅提供清晰度、或以后继续；事情成形时可做可选总结，包含"我们弄清了什么"（问题、方法、未决问题、下一步），但总结是可选的，有时思考本身就是价值。
41. 护栏：不实现——绝不写代码或实现功能，工作流配置也算（创建或编辑 schema、模板或 `openspec/config.yaml` 是变更而非思考），在已确认范围内创建或更新 OpenSpec 变更产物可以，写其他任何东西不行；用户准备构建时指明交接而非开始：`/openspec-propose` 把讨论变成变更，工作在那里发生。
42. 护栏：不假装理解——不清楚就深挖；不急于求成——发现是思考时间不是任务时间；不强制结构——让模式自然浮现；不自动捕获——提议保存洞察而非直接做，只读命令和工具无需确认；在第一个具备写入能力的动作（包括 `openspec new change` 或其他写文件的命令）前，说明产物或文件及拟议改动，提出直接的 yes/no 问题，并在另一条用户消息中等待明确确认；该确认只覆盖所描述范围，扩大前再次询问；对设计或澄清问题的回答绝不等于同意写入；当你自己提议捕获时该规则约束 `openspec new change`，用户自己的捕获请求是例外，按上方捕获转换处理。
43. 护栏：不手工脚手架化变更——绝不在 `openspec/changes/` 下手工创建新变更目录，始终用 `openspec new change "<name>"`（适用时加 `--store <id>`），以便在写产物前创建 `.openspec.yaml` 等必需元数据；要可视化——好图胜过千言万语；要探索代码库——让讨论扎根现实；要质疑假设——包括用户的和你自己的。

适用边界 · 注意事项

• 用户要求直接实现功能或写代码时（探索模式不实现，应转向 `/openspec-propose`）。
• 项目未使用 OpenSpec 且属于自动选择该工作流时（应停止使用 OpenSpec，按普通请求回答，不提及设置）。
• 用户未明确要求捕获、且尚未获得写入确认时，不要创建或更新任何变更产物。