القائمة
构建和完善项目的领域模型。当用户需要确定领域术语或统一语言（Ubiquitous Language）、记录架构决策，或其他 skill 需要维护领域模型时使用。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| name | domain-modeling |
| description | 构建和完善项目的领域模型。当用户需要确定领域术语或统一语言（Ubiquitous Language）、记录架构决策，或其他 skill 需要维护领域模型时使用。 |
在设计过程中主动构建和完善项目的领域模型。这是一门主动的学科——质疑术语、创造边界场景、在术语和决策形成的瞬间将其记录在案。（仅仅阅读 CONTEXT.md 来获取词汇不是此 skill 的用途——那是任何 skill 都能做的单行习惯。此 skill 用于你在修改模型，而非仅仅消费它。）
大多数 repo 只有一个 context：
/
├── CONTEXT.md
├── docs/
│ └── adr/
│ ├── 0001-event-sourced-orders.md
│ └── 0002-postgres-for-write-model.md
└── src/
如果根目录存在 CONTEXT-MAP.md，则该 repo 有多个 context。该 map 指向每个 context 的位置：
/
├── CONTEXT-MAP.md
├── docs/
│ └── adr/ ← 系统级决策
├── src/
│ ├── ordering/
│ │ ├── CONTEXT.md
│ │ └── docs/adr/ ← context 特定决策
│ └── billing/
│ ├── CONTEXT.md
│ └── docs/adr/
懒加载创建文件——仅当有内容需要写入时才创建。如果 CONTEXT.md 不存在，在第一个术语确定时创建。如果 docs/adr/ 不存在，在第一个 ADR 需要时创建。
当用户使用与 CONTEXT.md 中已有语言冲突的术语时，立即指出。"你的 glossary 将 'cancellation' 定义为 X，但你似乎指的是 Y——到底是哪个？"
当用户使用模糊或过载的术语时，提出精确的标准术语。"你说 'account'——指的是 Customer 还是 User？它们是不同的东西。"
当领域关系被讨论时，用具体的场景进行压力测试。创造能够探测边界案例的场景，迫使用户精确描述概念之间的界限。
当用户陈述某事物的工作方式时，检查代码是否一致。如果发现矛盾，指出："你的代码取消了整个 Orders，但你刚才说部分取消是可能的——哪个是对的？"
当术语确定时，立即更新 CONTEXT.md。不要批量处理——在发生时即时捕获。使用 CONTEXT-FORMAT.md 中的格式。
CONTEXT.md 应完全不含实现细节。不要将 CONTEXT.md 视为 spec、草稿本或实现决策的仓库。它是 glossary，仅此而已。
仅当以下三个条件同时满足时才提供创建 ADR：
如果缺少任何一条，跳过 ADR。使用 ADR-FORMAT.md 中的格式。
一轮一轮地同时询问所有前沿问题，进行无情的盘问。
把你无法独自回答的决策转化为一份问卷，交给别人来填写。
使用并行子代理为一个模块生成多种截然不同的接口设计方案。当用户想要设计 API、探索接口选项、比较模块形态，或提到"设计两次"时使用。
交互式 QA 会话，用户以对话形式报告 bug 或问题，代理负责提交 GitHub Issue。在后台探索代码库以获取上下文和领域语言。当用户想要报告 bug、进行 QA、以对话形式提交 Issue，或提到"QA session"时使用。
通过用户访谈创建包含微小提交的详细重构计划，然后将其提交为 GitHub Issue。当用户想要规划重构、创建重构 RFC，或将重构拆分为安全的增量步骤时使用。
从当前对话中提取 DDD 风格的通用语言（Ubiquitous Language）词汇表，标记歧义并提出规范术语。保存到 UBIQUITOUS_LANGUAGE.md。当用户想要定义领域术语、构建词汇表、强化术语体系、创建通用语言，或提到"领域模型"或"DDD"时使用。