用途：explore 是 Beat 中的探索模式，适合在决定变更前思考想法、需求或问题，调研代码库以理解架构、可行性与隐藏复杂度，以及在不产出代码的前提下比较方案、暴露风险。不用于产出规范工件、拆解任务、实现代码或从现有代码提取规范。触发示例包括“让我想清楚 X”“调查为什么会出现 Y”“Z 有哪些选项”。
主要能力：以思考伙伴的姿态进行探索，不设固定步骤与强制产出。可以追问澄清问题、挑战假设、重新定义问题、寻找类比；调研代码库、梳理相关架构、寻找集成点、识别模式与隐藏复杂度；头脑风暴多种方案、构建对比表、勾勒取舍；用 ASCII 图辅助可视化架构、状态机与数据流；识别风险与未知，建议做技术验证或调研。
使用方式：开始时会检查 beat/changes/ 目录中的现有变更并阅读其工件作为上下文。在探索开始时，若已安装 brainstorming 超能力，必须先调用它；不可用则直接进入思考姿态。当没有变更时，可自由思考，洞察成熟后提示是否创建变更（转 /beat:design）。当存在相关变更时，阅读 proposal.md、features/*.feature、design.md、tasks.md 等工件并在对话中自然引用；发现新行为或行为变更可记入 features/<name>.feature，设计决策可记入 design.md，范围变化记入 proposal.md，新工作记入 tasks.md。若设计决策满足难以逆转、出人意料、存在真实取舍三个条件，可建议记录到 docs/adr/；写 ADR 前需读取 beat/config.yaml 并应用 rules.adr，优先使用项目的 docs/adr/TEMPLATE.md；有活跃变更时 source 设为该变更目录，否则为 /beat:explore。是否记录由用户决定，不自动捕获。
适用场景与限制：适合需求澄清、方案对比、代码库调研与风险识别。限制是绝不编写应用代码或实现功能，只能读取、搜索与调查；用户要求实现时应提示先退出探索模式。探索没有必需终局，可转入行动、更新工件、仅提供清晰认识或稍后继续。不要伪造理解，不要催促，不要强行结构化，不要自动保存洞察。需注意避免以“用户想要快速答案”“主题太简单”“用户说跳过头脑风暴”等理由跳过结构化思考。