用途：当代码库让人感觉混乱、难以修改或“不适合 AI”时，用该技能找出架构摩擦点，并提出把浅模块加深的重构建议，以提升可测试性、AI 可导航性和杠杆效应。也可在准备大规模 AI 驱动改动前先降低风险。若只是发布小功能，应改用 /incremental-tdd。
主要能力：先读取项目上下文（如 CONTEXT.md、docs/glossary.md 等领域词汇表，以及 docs/adr/ 等架构决策记录），再借助 Agent 工具以 subagent_type=Explore 有机地探索代码库，从主应用、顶层路由、CLI 命令或用户指定区域入手，记录理解一个概念需在多个小模块间跳转、模块浅、纯函数仅为可测试性而抽取、紧耦合模块跨缝泄漏、未测试或难以测试等摩擦点，并用删除测试判断模块是否只是直通。随后给出编号的加深机会清单，每项包含涉及文件、问题、解决方案和收益（以局部性和杠杆效应说明，并说明测试如何改善）。用户选定候选后进入“拷问循环”，逐步厘清约束、依赖、加深模块的形态、缝后内容与可存活的测试。
使用方式：技能引用位于 references/ 文件夹，包括 GLOSSARY.md（建议中使用的词汇）、DEPTH-GUIDE.md（依赖分类与跨缝测试）、INTERFACES.md（探索替代接口）。建议中须严格使用词汇表术语：模块、接口、实现、深度、缝、适配器、杠杆、局部性，不得替换为“组件”“服务”“API”“边界”。若候选与现有 ADR 冲突，仅在摩擦足够真实时提出并明确标注。命名新概念时可懒创建 CONTEXT.md，用户以持久理由拒绝候选时可提议记录为 ADR。
适用场景：代码库难以导航和测试、希望提升可测试性、准备投入大量 AI 驱动改动前降低风险。
限制：不适用于只想发布小功能的情况；不提出接口，需先询问用户想探索哪个候选；避免框架教条，沿用现有语言与框架习惯；若用户只有时间做快速改进，应相应调整建议。后续可推荐 /incremental-tdd、/spec-writer 和 /slice-the-spec 等技能。