用途
domain-model 用于把一段关于业务实际运作方式的描述，转化为领域模型文档。其核心立场是：凭空发明的模型比没有模型更糟——它看起来很流畅、自信，却是错的，日后还会以业务中无人认识的名称进入代码。因此技能要求模型中每个概念都能追溯到用户说过的内容。
主要能力
该技能产出五类内容，且只有这五类：
- 语言（Language）：业务方使用的词，含义就是业务方所指的含义，需逐字保留原话。
- 流程（Flow）：按顺序排列的事件，使用过去时，表示某事已经成真。
- 规则（Rules）：形如“每当 X 发生，我们就做 Y”的条件分支与例外。
- 聚合（Aggregates）：保护某条规则并发出对应事件的对象。
- 上下文（Contexts）：某个词在此处不再是同一含义的边界。
技能明确不产出实体与值对象的区分、仓储、数据库 schema、类图，也不读取代码——因为代码已经选定了命名，读代码会让既有命名混入模型。
使用方式
工作流分五步：
- 捕获流程：接收用户提供的流程描述，可以是文字，也可以是文件路径（如转录稿、工单、会议记录）。若为空，则请用户讲述流程现状，包括手工环节和例外。保留原始措辞，不做整理。
- 采集语言：在建模前逐字提取用户用于业务事物的名词和动词。特别记录两类发现：两个词同一含义（如 cancel 与 void），以及一个词两种含义（如 customer 既指付费者也指求助者）。以列表形式回放给用户确认。
- 访谈：每轮 2 到 4 个问题。首次使用聚合、上下文、事件等术语时，用业务自身的说法解释。以提出候选模型代替直接提问，便于用户接受或反驳。不得命名用户未使用过的概念；确需引入时须标注为提案。事件须为过去时且业务可观察；规则是条件分支而非事件；聚合用来回答“谁来拒绝”；上下文在用户中途限定词义时出现。三轮后仍未解决的放入 Unresolved。
- 保存前展示：填写模板并整份贴出供审阅，同时列出“我引入的或只因我提问才被命名的术语”和“你未回应但我保留的提案”两行，即使为空也要显示。用户确认后才保存。
- 写入文件：写入仓库根目录下的 docs/domains/<slug>.md，使用 kebab-case 并以流程命名。若文件已存在，同一流程询问替换还是修订，不同流程则另选 slug。写入内容须与已批准草稿完全一致。
适用场景
适用于需要从业务口述中梳理领域语言、事件顺序、业务规则与边界，并形成可供后续实现对照的文档的场景。尤其适合包含手工环节和例外的复杂流程。
限制
模型描述业务，不包含后续要构建什么（待办列表、路线图、工作排序）。技能提醒模型会随时间腐化，因为没有东西在它漂移时重新编译；一份正确而简短的模型优于一份无人信任的详尽模型。