菜单
设计深模块的共享术语体系。当用户想要设计或改进某个模块的接口、寻找加深（deepening）的机会、决定接缝（seam）放在哪里、让代码更易测试或更利于 AI 导航时，或当其他技能需要用到深模块术语时使用。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
从两个维度审查自某个固定基点（提交、分支、标签或 merge-base）以来的改动 —— 规范（代码是否遵循本仓库有文档记录的编码规范？）与 需求（代码是否符合最初发起的 issue/PRD 的要求？）。以并行子代理运行两项审查并并排汇报。当用户想要审查某个分支、PR、进行中的改动，或要求“审查自 X 以来的改动”时使用。
基于一份规格或一组工单来实现一部分工作。
构建并打磨项目的领域模型。当用户想要确定领域术语或统一语言（ubiquitous language）、记录架构决策，或当其他技能需要维护领域模型时使用。
通过一场刨根问底的访谈来打磨一份计划或设计。
通过一场刨根问底的访谈来打磨一份计划或设计，并在过程中同时产出文档（ADR 和词汇表）。
就一份计划、决策或想法对用户刨根问底地追问。当用户想要对自己的思路进行压力测试，或使用了任何 'grill' 触发短语时使用。
| name | codebase-design |
| description | 设计深模块的共享术语体系。当用户想要设计或改进某个模块的接口、寻找加深（deepening）的机会、决定接缝（seam）放在哪里、让代码更易测试或更利于 AI 导航时，或当其他技能需要用到深模块术语时使用。 |
设计深模块（deep module）：在小接口背后承载大量行为，置于一个清晰的接缝处，并可通过该接口进行测试。无论在何处设计或重构代码，都使用这套语言和这些原则。目标是：为调用方带来杠杆（leverage），为维护者带来局部性（locality），为所有人带来可测试性（testability）。
请精确使用这些术语——不要用「组件（component）」「服务（service）」「API」或「边界（boundary）」来替代。语言的一致性正是全部要点所在。
模块（Module） —— 任何具有接口和实现的东西。刻意做到与规模无关：可以是一个函数、类、包，或跨层的一段切片。避免：单元（unit）、组件（component）、服务（service）。
接口（Interface） —— 调用方为正确使用该模块所必须了解的一切：类型签名，以及不变量、顺序约束、错误模式、必需的配置和性能特征。避免：API、签名（signature）（太狭窄——它们只指类型层面的表层）。
实现（Implementation） —— 模块内部的东西，它的代码主体。与**适配器（Adapter）**有别：一个东西可以是「小适配器 + 大实现」（如 Postgres 仓储），也可以是「大适配器 + 小实现」（如内存伪实现）。当接缝是讨论主题时，用「适配器」；否则用「实现」。
深度（Depth） —— 接口处的杠杆：调用方（或测试）每学习一个单位的接口，能够驱动多少行为。当大量行为藏在小接口背后时，模块是**深（deep）的；当接口几乎与实现一样复杂时，模块是浅（shallow）**的。
接缝（Seam） （Michael Feathers） —— 一个你无需在此处编辑就能改变行为的位置；模块接口所在的地点。接缝放在哪里本身就是一项独立的设计决策，与接缝背后放什么有别。避免：边界（boundary）（因与 DDD 的限界上下文含义重叠而被过度使用）。
适配器（Adapter） —— 在某个接缝处满足接口的具体事物。它描述的是角色（填补哪个槽位），而非实质（内部是什么）。
杠杆（Leverage） —— 调用方从深度中获得的东西：每学习一个单位的接口就获得更多能力。一份实现可在 N 个调用点和 M 个测试中反复收益。
局部性（Locality） —— 维护者从深度中获得的东西：变更、缺陷、知识和验证都集中在一处，而非散落到各个调用方。修一次，处处皆修。
深模块 = 小接口 + 大量实现：
┌─────────────────────┐
│ Small Interface │ ← Few methods, simple params
├─────────────────────┤
│ │
│ Deep Implementation│ ← Complex logic hidden
│ │
└─────────────────────┘
浅模块 = 大接口 + 少量实现（应避免）：
┌─────────────────────────────────┐
│ Large Interface │ ← Many methods, complex params
├─────────────────────────────────┤
│ Thin Implementation │ ← Just passes through
└─────────────────────────────────┘
设计接口时，问自己：
好的接口让测试变得自然：
接受依赖，而非创建依赖。
// Testable
function processOrder(order, paymentGateway) {}
// Hard to test
function processOrder(order) {
const gateway = new StripeGateway();
}
返回结果，而非产生副作用。
// Testable
function calculateDiscount(cart): Discount {}
// Hard to test
function applyDiscount(cart): void {
cart.total -= discount;
}
小表面积。 方法越少 = 需要的测试越少。参数越少 = 测试搭建越简单。
interface 关键字或类的公有方法：太狭窄——这里的接口包含调用方必须了解的每一个事实。