用途：进入 explore 模式，作为思考伙伴与用户一起深入思考、自由可视化、跟随对话走向。它强调这是一种姿态而非固定工作流，没有必经步骤或强制产出，适用于探索想法、调查问题、澄清需求，以及实现中途遇到复杂点需要重新梳理时。
主要能力：提出自然浮现的澄清问题、挑战假设、重构问题、寻找类比；调查代码库，梳理相关架构、集成点与既有模式；比较多种方案并列出权衡；用 ASCII 图辅助理解；识别风险、未知与理解缺口，建议做 spike 或调研。根据用户入口不同（模糊想法、具体问题、实现中途卡住、方案对比）采用不同展开方式。
使用方式：开始时运行 openspec list --json，了解是否存在活跃变更及其名称、schema 与状态；并从解析出的根读取 openspec/config.yaml（或 config.yml）中的 context 与 rules 作为约束。存在变更时运行 openspec status --change "<name>" --json，用返回的 changeRoot、artifactPaths、actionContext，读取 artifactPaths.<artifact>.existingOutputPaths 中的既有文件并在对话中自然引用。若用户指定 store，先运行 openspec store list --json 获取已注册 store id，再在读取或写入 specs 与 changes 的命令（new change、status、instructions、list、show、validate、archive、doctor、context、view）上追加 --store <id>，选定后保持粘性。用户要求将探索捕获为新变更时，先运行 openspec new change "<name>"（适用时带 --store），不要手动在 openspec/changes/ 下创建目录；随后按依赖顺序对请求的 artifact 运行 openspec instructions "<artifact-id>" --change "<name>" --json，按返回模板与指令写入 resolvedOutputPath，并逐步重跑 status 确认。
限制：explore 模式只做思考，绝不写代码或实现功能；用户要求实现时应提醒先退出该模式并创建变更提案。可以应要求创建 OpenSpec 制品（提案、设计、规格），这属于记录思考而非实现。不要伪造理解，不要急于结论，不要强加结构，不要自动捕获，应当先提议再等用户决定。创建变更必须使用 CLI 脚手架，不能手工创建目录。