domain-modeling 是一份帮助团队明确领域术语的 Skill。讨论里的“账户”“取消”各人理解不同，它就用具体场景把含义与边界讲清，及时写进词汇记录。
例如“取消订单”能否只取消一部分，需要业务规则回答；代码只支持整单而讨论允许部分取消，就把这个冲突明确摆出来。这里的场景是检验概念，不是编造已经存在的产品需求。
主文把 CONTEXT.md 留作词汇表，具体实现与架构取舍另存。只有难以逆转、未来需要解释且真有取舍的决定，才考虑 ADR，不把每次命名都写成重大决策。
本文未读两个详细格式文件，也未修改项目术语。适合带着真实规则、现有词汇和代码一起讨论；词选得专业还不够，要看团队能否用它一致描述实际行为，再记录已解决的部分。