用途：在编写任何代码之前，用结构化对抗式提问对计划做压力测试。把计划建模为一棵设计树，每个决策分支出依赖它的后续决策，再分轮次访谈用户，直到每个分支都被解决、没有默认假设被悄悄跳过。
何时使用：用户说 grill me、interview my plan、stress test this idea；复杂工作前，如认证流程、schema 变更、迁移、支付；计划存在未解决决策或显得含糊；在 subagent 驱动的开发分解之前。不适用于已有代码（应改用 requesting-code-review）或简单的一次性任务。无需前置条件，可用于任何计划或原始想法。
核心机制：前沿轮次。前沿指所有前置条件已确定、现在就能提问而无需猜测答案的决策。按轮次工作：在一条消息中提出当前全部前沿问题，编号，每题附带推荐答案，然后等待。若某题答案依赖本轮中另一未决问题，它属于后续轮次。每题按“❓ Q1 — 标题、正文、可选选项”与“➡️ 推荐：答案加一行理由”的格式写出。每次回答都会重塑设计树，使前沿外推并解锁依赖问题，随后重新计算前沿并提问下一轮。
事实由你负责，决策归用户。前沿问题若需要环境事实（代码库、文件系统、配置、文档），应自行用 search_files、read_file、terminal 查找，或通过 delegate_task 派子代理做重探索，绝不向用户询问可自行查到的东西；也不要因探索而阻塞，只有其下游问题需等待，其余前沿照常提问。
问题覆盖：理解层——真实目标与边界，明确范围内外、约束、用户；技术决策——架构选择理由、失败场景、最坏情况、回滚方式，并对照现有代码库指出既有模式；边界情况——用户异常操作、依赖宕机、流量百倍、安全隐患。
综合：当前沿为空时，用要点总结所有决策，列出仍开放的事项和明确排除的范围，询问“已对齐？可以开始实现，还是需要调整？”，在用户确认共识前不执行计划。
常见陷阱：按依赖顺序提问，避免依赖未决问题；跳过代码库；接受“我不知道”为最终答案；盘问期间写代码；过于附和；不适应用户语言。验证清单：本轮每题前置条件均已确定、每题给出推荐、通过代码库查事实、综合前前沿为空、产出决策与开放项总结、停止前确认对齐。