domain-modeling

领域建模

明确项目的领域概念及塑造这些概念的决策。定义或修订这些含义时使用此技能；单纯阅读现有术语表无需进行建模会话。

选择工作模式

• 讨论或拟议修改： 对于讨论、审阅或只读请求，请在对话中保留定义、决策和拟议的文档变更。不要创建或编辑文件。
• 文档更新： 当用户要求创建或维护领域文档，或要求执行包含记录内容的工作流时，在指定范围内写入已确定的术语和相关决策。对于已获得的授权，无需每条记录都再次询问。如果写入权限仅限于特定文档，请将其他拟议记录保留在对话中。

仅加载此技能并不代表获得文档写入授权。如果请求未明确表示要写入内容，请继续使用讨论模式。记录模型并不代表获准实现它或重命名代码。

查找现有文档

检查仓库指南和相关文档，了解当前的术语表、上下文映射、ADR 位置和文档格式。创建任何内容之前，遵循现有的命名、链接、上下文归属和编号。如果术语表或 ADR 目录使用了不同名称，并不意味着缺少相关文档。

如果没有现成约定，请使用 CONTEXT.md 记录领域术语，并使用 docs/adr/ 记录架构决策。仅在文档更新模式下，且已有约定内容需要记录时，才创建这些文件。使用现有上下文映射（无论文件名是什么）来定位领域专属记录；不要仅因根目录存在 CONTEXT.md，就推断整个项目只有一个上下文。

会话期间

对照术语表核验

将预期含义与术语表进行比较。如果冲突会改变领域区分、行为、归属或契约，请提出并确认。对于显然指向同一概念的普通同义词或措辞差异，无需打断；在回复中使用既定术语即可。

澄清模糊表述

结合上下文和现有证据，解读含义宽泛的术语。如果仍存在实质不同且合理的解释，请说明区别并提出有针对性的问题。在有帮助时建议一个规范术语，但不要把建议当作已达成的变更，也不要仅为措辞一致而纠正用词。

讨论具体场景

当具体场景有助于区分不同的合理含义或揭示尚未解决的领域规则时，请使用这些场景。聚焦可能改变当前决策的情况；不要仅为延长讨论而罗列边缘案例。

对照代码核验

如果相关代码有助于确认当前行为或澄清重要区别，请检查代码。将已实现行为与用户预期的模型分开处理。如果两者不一致，请确认用户描述的是计划中的变更、对过时文档的修正，还是在解决不一致；不要仅因代码尚未跟上，就重新讨论已经明确的决策。

记录已确定的含义

在文档更新模式下，术语含义一经明确，就将其记录到现有术语表中。在讨论模式下，请在回复中保留已达成一致的定义或拟议文本。只有当项目没有既定格式时，才使用 CONTEXT-FORMAT.md。

术语表条目应聚焦于领域含义。将实现决策放入相应的架构记录，而不是定义中。保留现有文档中无关的部分；不要将多用途的 CONTEXT.md 改造成仅包含术语表的文件。将尚未解决的提议和假设与已达成一致的内容区分开来。

仅将符合条件的决策记录为 ADR

符合以下全部三项条件的决策，才应记录为 ADR：

1. 难以撤销：日后改变主意的成本不可忽视
2. 缺少背景时令人意外：未来的读者会疑惑“为什么要这样做？”
3. 源于真实的权衡或外部约束：存在真正的替代方案，而你基于具体原因选择了其中一个；或者代码中看不出来的约束排除了显而易见的选项

如果缺少任何一项，请勿创建或建议 ADR。当文档更新已获授权时，无需再次请求批准，即可记录符合条件且已确定的决策。否则，请在对话中提出记录建议。遵循项目的 ADR 格式；如果没有约定，请使用 ADR-FORMAT.md；其中也列出了符合条件的决策示例。

完成

总结已厘清的含义和决策、尚待解决的重要问题，以及已更新或建议更新的文档。回读已写入的更改，确认其表达了双方达成一致的含义，并保留了现有上下文。在讨论模式下，不要声称建议的文本已保存。