用途：当 Rails 应用的主要问题不是语法或风格，而是领域边界不清时使用。适用于仓库把多个业务概念混在同一模型或服务命名空间下、团队争论归属与边界、架构审查发现跨域耦合等场景。
主要能力：检查限界上下文（是否有独立语言、规则与归属）、上下文泄漏（某区域随意触及另一区域概念）、共享模型（同名对象含义冲突）、编排（用例协调多个上下文却无明确归属者）、归属（谁拥有不变量、状态转换与副作用）。
使用方式：按顺序审查——从控制器、任务、服务、API 与 UI 流程等入口点开始映射；按业务能力而非现有文件夹命名来命名上下文；查找跨越边界的术语、校验、工作流或副作用；确定各上下文应拥有的不变量、转换与外部副作用；提出最小可信改进（重命名、抽取、隔离或包装），再考虑大规模重组。输出先写发现，每条包含严重程度、涉及上下文、泄漏术语或归属冲突、当前边界的风险、最小可信改进，最后列出待解决问题与建议的后续技能。
硬性约束：除非业务边界明确到可以命名，否则不要建议拆分为新上下文；不要自动把每个大模块当作限界上下文；提出结构变更前必须先指出泄漏语言或归属冲突。
限制与常见错误：并非所有应用都需要大量上下文，过度拆分只会增加仪式感；仅看目录结构不能证明领域边界；用共享工具模块解决泄漏往往掩盖归属问题；不建议一上来就重写。
可衔接技能：术语模糊时接 ddd-ubiquitous-language；上下文清晰需战术建模时接 ddd-rails-modeling；需更广 Rails 结构审查时接 rails-architecture-review；需增量抽取时接 refactor-safely。