用途：在代码库中寻找架构摩擦点，提出“深化机会”——把浅模块改造为深模块的重构建议，目标是提升可测试性与 AI 可导航性。该技能受项目领域模型影响：领域语言为好的接缝命名，ADR 记录不应被重新争论的决策。
主要能力：使用统一术语（Module、Interface、Implementation、Depth、Seam、Adapter、Leverage、Locality），避免使用 component、service、API、boundary 等词。核心原则包括删除测试（删除模块后复杂度消失说明是直通模块，复杂度在 N 个调用方重现说明其有价值）、接口即测试面、一个适配器是假设接缝、两个适配器才是真实接缝。
使用方式：先阅读领域词汇表与相关 ADR，再用 Agent 工具以 subagent_type=Explore 探索代码库，记录摩擦点，如理解一个概念需在多个小模块间跳转、模块浅、纯函数仅为可测试性抽取但真实缺陷藏在调用方式中、紧耦合模块跨接缝泄漏、未测试或难以通过当前接口测试的部分。随后以编号列表呈现候选，每项包含 Files、Problem、Solution、Benefits（用 locality 与 leverage 及测试改进说明），使用 CONTEXT.md 的领域词汇与 LANGUAGE.md 的架构词汇。若候选与 ADR 冲突，仅在摩擦足够真实时提出并明确标注。此时不提出接口，先询问用户想探索哪个。用户选定后进入 grilling 对话，走查设计树：约束、依赖、深化模块的形态、接缝背后内容、哪些测试保留。决策成形时内联处理副作用：新概念加入 CONTEXT.md，模糊术语就地更新；用户以关键理由拒绝候选时，可提议记录为 ADR，仅当该理由对未来探索者避免重复建议确有必要时。
适用场景：用户希望改进代码库架构、发现重构机会、提升可测试性或 AI 可导航性时。
限制：资料未提供具体安装命令、平台支持、收费方式或效果数据；不提出接口设计，需用户先选择候选；ADR 冲突仅在摩擦真实时提出。