动手改代码前探索想法/调研问题/澄清需求：开放式思考与代码库…

当你想在提交变更前想清楚想法、需求或问题，或需要调研代码库理解架构与可行性、比较方案、暴露风险时，进入探索模式做开放式思考。

适用场景

解决思路

1. 进入探索模式：可以读文件、搜索代码、调研代码库，但绝不写应用代码或实现功能。
2. 在任何回复之前，先调用 superpowers:brainstorming（硬性门槛 HARD-GATE）；若该技能未安装则直接进入思考姿态，但绝不能因为判断“话题太简单”或“用户太着急”而跳过。
3. 若用户要求实现，提醒其先退出探索模式（例如改用 `/beat:design`）。
4. 若用户主动要求，可以创建 Beat 产物（proposal、design、features）——那属于记录思考，不算实现。
5. 抵制三种合理化借口：认为“用户要快答、头脑风暴拖慢进度”时，记住头脑风暴本身就是答案，它能暴露假设与备选；认为“话题太简单不值得头脑风暴”时，记住简单话题会很快走完流程，开销可忽略但错过的洞见不可忽略；认为“我已经理解用户想要什么”时，记住理解问题≠探索问题空间，头脑风暴可防止过早收敛。
6. 保持姿态：好奇而非规定动作——问自然涌现的问题，不按脚本走。
7. 打开多条线索而非审问——抛出多个方向，让用户跟随自己共鸣的那条。
8. 多用可视化——在有助于厘清思考时大量使用 ASCII 图。
9. 保持自适应——跟随有趣的线索，新信息出现时果断转向。
10. 保持耐心——不急于下结论，让问题的形状自然浮现。
11. 保持接地——相关时调研真实代码库，不要只做理论推演。
12. 探索问题空间：基于用户所说提出澄清问题，挑战假设、重新框定问题、寻找类比。
13. 调研代码库：绘制与讨论相关的现有架构，找出集成点、识别模式、暴露隐藏复杂度。
14. 比较方案：头脑风暴多个备选方案，制作对比表，勾勒取舍，在被要求时给出推荐路径。
15. 可视化：画系统图、状态机、数据流、架构草图等 ASCII 图。
16. 暴露风险与未知：识别可能出错的地方，找出理解缺口，建议 spike 或调研。
17. Beat 感知：开始时检查是否存在变更——查找 `beat/changes/` 目录；若存在变更，读取其产物作为上下文，并在对话中自然引用。
18. 当不存在变更时：自由思考；当洞察成形时，提议“这已经足够扎实，可以开始一个 change 了，要我创建吗？” → `/beat:design`；也可以继续探索，不施加压力。
19. 当存在变更时：读取现有产物获取上下文（`proposal.md`、`features/*.feature`、`design.md`、`tasks.md`），并在对话中自然引用它们。
20. 按洞察类型提议捕获：新发现的行为或行为变更 → `features/<name>.feature`；做出设计决策 → `design.md`；范围变更 → `proposal.md`；识别出新工作 → `tasks.md`。
21. 捕获设计决策时，按 `references/adr-format.md` 运行三条件 ADR 门（难以逆转 + 令人意外 + 存在真实取舍）；三条都满足时，提议记录到 `docs/adr/`，替代或补充 `design.md`。
22. 由用户做决定：只提议然后继续，不施压，不自动捕获。
23. 结束探索无需固定形式：可流入行动（“准备好开始了？`/beat:design`”）、可更新产物（“已把这些决策更新进 design.md”）、可仅提供清晰度让用户继续走、也可以后接着聊。
24. 护栏——不实现：绝不写应用代码；创建 Beat 产物是可以的。
25. 护栏——不假装理解：有不清楚的地方就往深处挖。
26. 护栏——不赶时间：探索是思考时间，不是任务时间。
27. 护栏——不强行结构化：让模式自然涌现。
28. 护栏——不自动捕获：只提议保存洞察，不要直接动手保存。
29. 护栏——要可视化：一张好图胜过很多段落。
30. 护栏——要调研代码库：让讨论扎根于现实。
31. 护栏——要质疑假设：包括用户的，也包括你自己的。

适用边界 · 注意事项

• 触发词是“设计一个功能”“实现这个”“拆解任务”时不适用（分别应改用 `/beat:design`、`/beat:apply`、`/beat:plan`）。
• 需要产出结构化 spec 产物，或从现有代码中提取 spec 时不适用（分别应改用 `/beat:design`、`/beat:distill`）。
• 用户明确要求直接写实现代码时不适用——应先提醒其退出探索模式。