用途：对一项计划做持续的访谈式追问，逐一走完设计树的每个分支，解决决策之间的依赖关系，最终形成共识。每个问题都会给出推荐答案，且一次只问一个问题，等待反馈后再继续。若某问题可通过查阅代码库回答，则改为直接查代码而非发问。
主要能力： 领域感知与文档识别。会话中探查代码库时也会寻找既有文档。多数仓库只有单一上下文：根目录含 CONTEXT.md，docs/adr/ 存放 ADR（如 0001-event-sourced-orders.md）。若根目录存在 CONTEXT-MAP.md，则仓库含多个上下文，该地图指向各上下文的所在位置，各上下文可有自己的 CONTEXT.md 与 docs/adr/。文件按需创建——有内容可写时才建：首个术语确定时创建 CONTEXT.md，第一个 ADR 需要时创建 docs/adr/。
术语治理：当用户用词与 CONTEXT.md 中的既有语言冲突时立即指出；对含糊或含义过载的词，提出精确的规范术语（例如区分 Customer 与 User）。
场景验证：讨论领域关系时，用具体场景施压测试，虚构探测边界情况的场景，迫使用户明确概念边界。与代码交叉核对：用户描述某行为时核对代码是否一致，不一致则当面提出矛盾点。
内联更新 CONTEXT.md：术语确定后立即就地更新，不批量积压；使用 CONTEXT-FORMAT.md 中的格式。CONTEXT.md 不与实现细节耦合，只收录对领域专家有意义的术语。
谨慎提供 ADR：仅在三项条件全部满足时才提议创建——难以逆转、缺少上下文会令人意外、是真实取舍的结果。缺一项即跳过，格式见 ADR-FORMAT.md。
适用场景：需要在写作代码前或过程中澄清领域概念、统一术语、记录关键架构决策的团队或个人开发者。
限制：资料未提供具体安装命令、收费与价格、平台支持范围、实际使用效果等信息。