用途：审查 Ruby 应用的 DDD（领域驱动设计）边界、模块边界、服务边界与代码组织，检测限界上下文、上下文泄漏、共享模型、编排与所有权问题。
主要检查项：限界上下文是否语言、规则与归属清晰；一个区域是否随意引用另一区域概念；同一对象名是否含义冲突；用例是否跨上下文协调却无明确所有者；不变量、状态转换与副作用的归属方是谁。
硬性约束：业务边界不能被明确命名时，不推荐拆分出新上下文；不把每个大模块自动当作限界上下文；提出结构调整前，必须先指出泄漏的语言或所有权冲突。
评审顺序：从控制器、任务、服务、API 与 UI 流程等业务入口开始映射；按业务能力而非仅按现有文件夹命名分组上下文；查找跨边界的术语、校验、工作流或副作用；判定哪个上下文应拥有不变量、转换与外部副作用；提出最小可信改进，优先重命名、抽取、隔离或包装，而非大规模重组。
可用搜索辅助定位跨上下文引用，例如：rg 'Billing.*Fleet|Fleet.*Billing' lib/ app/；rg 'Billing::[A-Z]' lib/services/fleet/ services/fleet/；rg 'Fleet::[A-Z]' lib/services/billing/ services/billing/；rg 'after_(create|update|save).*Job|after_(create|update|save).*Mailer' lib/ app/；rg 'invoice|Invoice|Billing' lib/ app/ services/。
常见陷阱：把共享数据库表当作共享上下文的证据；在业务语言尚不稳定时拆分上下文；仅因 Ruby 命名空间大就当作限界上下文。
所有权方向：应明确写出“上下文 X 拥有某能力；上下文 Y 不得执行某动作”，例如计费拥有发票状态与发票生成触发，车队不得直接写发票列或直接调用计费生成器，而应发布事件。
输出风格：每条发现包含严重性、涉及上下文、泄漏术语或所有权冲突、风险原因与最小可信改进；先写发现，再列未决问题与建议衔接技能；默认使用英文。需要具体泄漏示例时再加载 EXAMPLES.md。
衔接：术语模糊时接 define-domain-language；上下文清晰需战术建模时接 model-domain；需增量抽取时接 refactor-process。
限制：官方资料未提供安装命令、版本要求与授权信息；具体适用项目规模与效果暂未提供。