用途：在创建 Issue 之前，先把一个模糊的想法或问题塑造成清晰、可执行的方案。输入为待塑造的想法或问题（$ARGUMENTS），可选附加执行上下文。未提供参数时会先询问用户想塑造什么。
主要能力与流程：
- 调查上下文：先探索代码库，寻找相关实现、模式与约束，识别集成点、依赖与架构边界，查看历史尝试或相关工作（git log、已关闭 Issue），并检索项目 Issue 跟踪器中的相关 Issue。
- 塑造问题：通过一次一个的结构化提问收敛出共享设计概念。若存在 CONTEXT.md 会读取并沿用其词汇。每个问题都基于第一步的事实，附带推荐答案（表述为“我建议 X，因为 Y”），等待用户回应；必要时提出质疑，例如与 CONTEXT.md 词汇冲突、与代码实际行为矛盾、或使用含糊术语时，提出精确的规范术语，并用具体场景压力测试模糊边界。
- 探索方案（可选）：若塑造阶段已得出清晰方案则跳过；若仍有多个可行方案，可委派 2-3 个并行子代理，各自采用截然不同的设计约束（最小改动、复用优先、扩展性优先、性能优先），生成结构不同的方案供用户选择、组合或全部否决。运行时不支持子代理时，可自行按不同约束依次生成。
- 总结方案：输出结构化摘要，包含问题陈述、选定方案、范围边界（范围内/范围外）、建议的 Issue 拆分、副作用（CONTEXT.md 术语增改、ADR 记录）。该摘要是 forge-create-issue 的输入。
副作用：术语确定时即时更新 CONTEXT.md，不批量处理；承载性决策（难以逆转、缺乏上下文会令人意外、且是真实权衡结果）可提议记录为 docs/adr/ 下的简短 ADR，目录按需创建。
停止条件：用户连续多个问题接受推荐答案、剩余问题属于品味层面而非决策层面，或共享设计概念已足够清晰可总结。
适用场景：想法尚不明确、需要先厘清问题再拆解任务时，例如“应用在移动端很慢”“需要更好的错误处理”“认证流程存在安全顾虑”。
限制：资料未提供具体安装方式、收费、平台支持或效果数据；方案探索步骤为可选，且依赖运行时是否支持子代理。