用途：把领域建模当作持续实践，在决策过程中主动挑战并维护项目的领域模型与统一语言，而不只是阅读 CONTEXT.md。
涉及文件：CONTEXT.md 为根术语表，只记录已确定的领域术语；CONTEXT-MAP.md 为可选的限界上下文地图，存在时用于选择适用的上下文术语；docs/adr/ 存放持久的架构决策记录。文件按需惰性创建，不要仅因技能启用就创建它们，只有出现值得保留的已确定内容时才创建或更新。
核心规则：把语言视为设计的一部分，挑战模糊词、重载术语和与既有用法冲突的术语；先讨论具体场景再命名抽象，优先使用真实工作流、用户、数据和代码路径中的例子；尽可能交叉引用代码库，若术语已出现在代码中，先检查相关文件再让用户定义；CONTEXT.md 仅作术语表，不用作实现规范、草稿、待办、决策日志或会议记录；术语确定后即时更新 CONTEXT.md，条目保持简短稳定；产品含义归用户所有，可建议更清晰的语言，但覆盖有争议术语前需先询问。
建模循环：识别当前上下文（有 CONTEXT-MAP.md 则据此定位限界上下文，否则从根 CONTEXT.md 和代码库入手）；提取对话、文档、工单、UI、API、schema 和代码中正在使用的术语；标记歧义、同义词、冲突及随上下文变义的术语；提出一个聚焦问题解决最重要的歧义；给出推荐术语或定义及支撑场景；用户接受或澄清后，若内容持久则更新术语表条目；重复直至模型足够清晰。
术语表格式：使用简洁 Markdown 条目，包含 Term、Definition（一到两句）、Use when（简短具体的使用规则）、Do not use for（相近概念或常见混淆，可选）。多限界上下文时，仅当项目已有该模式才用标题或上下文专属文件，否则保持根术语表简单。
ADR 纪律：仅在决策难以逆转、无上下文会令人意外、且存在真实权衡时创建 ADR，路径为 docs/adr/<yyyy-mm-dd>-<slug>.md，包含 Status、Context、Decision、Consequences、Options Considered。日常实现细节、临时计划或明显的局部选择不写 ADR。除非用户明确要求，写 ADR 前先询问。
限制：资料未提供具体平台、收费、价格或效果信息。