用途：当 Rails 功能、缺陷或架构讨论中的业务术语模糊、含义重叠或不一致时，使用该技能建立领域驱动设计（DDD）的通用语言。核心原则是先就业务语言达成一致，再选择模型、服务或边界。
主要能力：为同一概念选定唯一业务术语；收集同义词并保留一个首选词；尽早标记一词多义的词并显式拆分含义；命名优先体现业务含义而非技术缩写；输出可用的术语表而非抽象理论。
使用方式：从需求、PRD、工单、现有文档和代码命名中收集候选名词、角色、状态、事件与动作；对同义词分组，识别一词多义；选定规范术语，别名仅作迁移说明或搜索提示；为每个术语写简短定义、预期不变量与相关概念；列出需用户确认或可能指向多个限界上下文的歧义项；随后按流程衔接 ddd-boundaries-review、ddd-rails-modeling、create-prd 或 generate-tasks。输出建议包含规范术语、别名/冲突词、定义、关键不变量或业务规则、可能相关上下文、待解决问题，可用表格呈现。
适用场景：同一业务概念出现多个说法；命名不清导致功能或缺陷讨论受阻；在做边界评审或 Rails 建模前需要术语表。
限制与硬性约束：不得脱离用户真实领域语言引入 DDD 术语；术语表未明确到足以支撑变更前，不得重命名代码概念；推荐建模变更前必须标记一词多义或冲突术语。常见错误包括长期保留所有同义词、把技术类名当作领域事实、未统一用词就跳到聚合、把所有歧义视为无害。危险信号包括同一术语在不同界面或服务中含义不同、类名与用户语言严重不符、用“基本一样”代替区分、术语表以技术行话为主。
其他事实（如收费、价格、平台支持）暂未提供。