用途
geek-skills-openspec-explore 是一个 OpenSpec 的“探索模式”（explore mode）技能，定位为思考伙伴，帮助用户探索想法、调查问题、澄清需求。它适用于用户想要深入思考、梳理问题或明确需求时。
主要能力
- 作为思考伙伴，跟随对话自然展开，不设固定步骤、必需顺序或强制输出。
- 可以读取文件、搜索代码、调查代码库，但绝不编写代码或实现功能。
- 如果用户要求实现，会提醒用户先退出探索模式并创建变更提案。
- 如果用户要求，可以创建 OpenSpec 工件（提案、设计、规格），因为这属于记录思考而非实现。
- 鼓励使用 ASCII 图辅助澄清思路，例如系统图、状态机、数据流、架构草图、依赖图、对比表。
- 具备 OpenSpec 上下文意识：开始时可通过
openspec list --json快速检查是否存在活动变更及其名称、模式和状态；当变更存在时，可读取openspec/changes/<name>/proposal.md、design.md、tasks.md等工件作为上下文，并在对话中自然引用。 - 当决策形成时，可提议将洞察记录到对应工件：新需求写入
specs/<capability>/spec.md，需求变更写入specs/<capability>/spec.md，设计决策写入design.md，范围变更写入proposal.md，新工作写入tasks.md，假设失效写入相关工件。是否记录由用户决定，不强制、不自动捕获。
使用方式
该技能没有固定工作流，是一种“姿态”而非流程。根据用户带来的内容，可能采取的行动包括：探索问题空间（提出澄清问题、挑战假设、重新表述问题、寻找类比）；调查代码库（梳理相关现有架构、寻找集成点、识别已有模式、暴露隐藏复杂性）；比较选项（头脑风暴多种方案、构建对比表、勾勒权衡、在被要求时推荐路径）；可视化（用 ASCII 图表达系统图、状态机、数据流、架构草图、依赖图、对比表）；暴露风险与未知（识别可能出错的地方、发现理解缺口、建议 spike 或调查）。
不同入口的处理示例：用户带来模糊想法时，可展开协作光谱（Awareness/Coordination/Sync）并询问用户当前想法；用户带来具体问题时，可读取代码库并绘制当前认证流程，指出多个纠缠点并询问哪个最紧急；用户卡在实现中途时，可读取变更工件，追踪涉及内容、绘制图、探索选项、建议路径，并询问是否更新设计或添加 spike 任务；用户想比较选项时，可先询问上下文，再结合约束给出对比。
结束方式没有强制要求：可能流入提案（“准备好开始了吗？我可以创建变更提案”）、导致工件更新（“已用这些决策更新 design.md”）、仅提供清晰思路、或稍后继续。当思路逐渐清晰时，可选地总结“我们弄清楚了什么”（问题、方法、开放问题、下一步），但该总结是可选的，有时思考本身就是价值。
适用场景
- 用户想要深入思考、梳理问题或明确需求时。
- 用户带来模糊想法、具体问题、实现中途的困惑，或想比较方案时。
- 需要结合 OpenSpec 变更工件进行上下文讨论时。
限制
- 不实现：绝不编写代码或实现功能；创建 OpenSpec 工件可以，编写应用代码不可以。
- 不伪造理解：不清楚就深入挖掘。
- 不急于求成：探索是思考时间，不是任务时间。
- 不强制结构：让模式自然浮现。
- 不自动捕获：提议保存洞察，而不是直接执行。
- 要可视化：一张好图胜过许多段落。
- 要探索代码库：让讨论扎根现实。
- 要质疑假设：包括用户的和自己的。
其他说明
该技能的官方文本、收费、价格、平台、效果或具体使用步骤等事实暂未提供。