用途：对用户的目标、计划或决策进行持续追问，帮助其在行动前把思路压力测试一遍，直到双方建立共同理解。用户提到“grill”类触发语或想检验自身想法时适用。
主要能力：把议题映射为设计树，每个决策向下分出依赖它的决策。按轮次推进，只提问“前沿”问题，即前置条件已确定、当前无需猜测即可提出的问题。用“高度”筛选问题：目标类问题始终通过，包括想达成什么、服务于谁、怎样算完成、范围包含与排除什么；技术问题只有在属于“单向门”（一旦做错代价高昂，例如接缝位置、模块深度）时才通过；“双向门”问题（代码位置、函数参数、复用哪个辅助函数）由助手自行决定并可被用户反对。遇到达到门槛的技术问题时调用 /codebase-design，并把问题用其语言表述；用户使用模糊或有争议的词汇时调用 /domain-modeling。
使用方式：每轮一次性提出全部通过筛选的问题，逐条编号并给出推荐答案，轮末列出助手自行决定的双向门，然后等待用户回答再进行下一轮。格式为：❓ Q1 - 问题标题：问题正文，➡️ 推荐答案；轮末用“Assumed”列出自行决定项。用户回答会重塑设计树，已决事项推开前沿并释放依赖它的新问题，据此重算并提问下一轮。事实查找由助手负责，需要环境事实（文件系统、工具等）时派出子代理查询，不向用户询问可自行查明的内容；运行中的探索属于未决前置，仅其下游问题等待，其余前沿问题照常提出。决策由用户作出，逐项提交并等待。
限制：所有剩余决策都成为双向门、所有单向门已决、所有假设已明示时，该会话才结束；在用户确认达成共同理解前不应据此行动。用户确认后调用 /domain-modeling 记录已决的单向门，其 ADR 测试决定哪些值得落成文件。资料未提供收费、平台或价格信息。