用途：当一个模块、API 或接口的形态不明确时，为其设计并比较多种方案。典型触发点：切片计划要求“新增模块 X”但 X 的形状不明显；两个调用方即将耦合到一个未刻意设计的接口；重构暴露出需要刻意重切的接缝。
核心原则：要“截然不同”，而非同一设计的变体。仅方法名不同的三个设计只是一个设计；隐藏不同内容、暴露不同控制维度或反转调用方/被调方关系的，才算三个设计。通过给每个子代理分配一个能强制产生不同形状的约束来保证真正分歧。关注接口而非实现：不估工作量，不争论实现难度，只争论接口从调用方角度看的行为及其内部隐藏的内容。
使用方式：第一步先collect需求，在对话中回答模块解决什么问题、谁调用（其他模块、外部用户、测试）、关键操作、约束（性能、兼容性、既有模式）、哪些应隐藏哪些应暴露；若用户未全部提供，最多一轮 1–3 个问题询问。第二步在单条消息中并行启动 3–4 个 Agent（subagent_type=general-purpose），每个拿到相同需求简报加一个发散约束：最少方法数（1 至 3 个入口）、最大化灵活性（多扩展点与组合）、优化最常见调用方（默认场景简单、高级场景可行），可选第四个围绕端口-适配器边界设计。每个代理返回接口签名（类型、方法、参数）、一个真实调用方的使用示例、该设计内部保留的复杂度、以及它不擅长的权衡。第三步按顺序逐个展示，让用户先感受每种形状，不要先给比较。第四步用散文（非表格）从简单性、深度（小接口隐藏大复杂度为佳）、通用性与专门化的平衡、形状对实现效率的影响、误用面等角度比较，突出分歧最大的地方。第五步有主见地推荐其中一个或提出混合方案，并用一段话说明理由。第六步用户选定后用 gsd_decision_save 保存所选形状与理由；若切片处于活动状态，用 gsd_summary_save（artifact_type: "CONTEXT"，slice_id）把接口草图保存到切片上下文。不编写实现，实现留到 execute 阶段。
限制：不要产出同一构想的三个变体；不要涉及文件路径、调用图或内部数据结构等实现细节；不要跳过比较直接问“你喜欢哪个”；不要按构建成本排序，要按调用方体验排序。