用途
该技能是事件建模（Event Modeling）的第 1 步，目标是从需求中头脑风暴出所有领域事件，提取系统可能拥有的每一个改变状态的事件。适用于开始事件建模时的需求梳理环节。
主要能力与流程
可选访谈阶段
资料给出何时访谈与何时跳过的判断条件：当用户已提供详细、文档化的需求（书面用户故事、功能规格、业务规则）时可跳过访谈；当需求含糊、不完整或领域专业性不确定时应进行访谈。
关键问题分四类：
- 需求完整性（决定头脑风暴是否可能穷尽）
- 领域专业知识与熟悉度（影响应由谁参与、需要何种引导）
- 已知复杂区域（决定头脑风暴投入与深度，如支付处理、状态转换、业务规则）
- 明确的业务规则与约束（确保无隐含假设，可能揭示缺失事件）
访谈流程设条件入口：若已提供书面需求或用户故事，且有文档化的业务规则或约束，且已指名将参与的领域专家，则跳过访谈直接进入头脑风暴；否则执行访谈。访谈分两阶段：阶段 1 需求评估（问题 1-2），阶段 2 复杂度映射（问题 3-4）。
访谈发现写入项目的事件建模文件：.trogonai/interviews/[project-name]/EVENTMODELING.md，使用 Write 工具添加或更新章节，内容包括需求评估、领域专业知识、角色目录（人类角色与系统参与者）、事件流（流根）、业务规则与约束、头脑风暴聚焦区域，并更新访谈轨迹表。
研讨会引导指南
设定为协作式头脑风暴研讨会，由引导者带领参与者快速设想系统并提取事件。
- 阶段 1：理解目标（5-10 分钟）——说明项目目标、解决什么问题、用户是谁、关键成果是什么。
- 阶段 2：自由头脑风暴（15-20 分钟）——引导者提问“这个系统中可能发生哪些事件？当某些东西发生变化时，会产生什么事件？”参与者报出事件（如 Customer places order、Order confirmed、Payment received、Inventory updated、Order shipped、Delivery confirmed、Return requested、Refund issued）。
- 阶段 3：温和过滤（10-15 分钟）——以对话方式引入“改变状态”的概念，区分改变状态的事件与非事件（如仅浏览目录不是事件，但选择商品改变了购物车内容，属于状态变更，可命名为 ItemAddedToCart；Payment received 使订单从已确认变为已支付，属于事件；Customer logged in 可能不是状态变更，除非跟踪登录；System checked inventory 是内部动作；Inventory reserved 是状态变更；Email sent 是通知；Notification requested 在跟踪偏好时可能是状态变更）。
引导者技巧：保持对话式提问、用参与者所在领域的例子（电商、银行）、不必僵化（不确定时先收录后细化）、捕捉“为什么”（事件为何重要、谁关心它）。
工作流分析步骤
- 识别用户角色与参与者（强制）——先定义谁与系统交互，列出人类角色（Customer、Seller、Admin、Support Agent、Reviewer 等）与系统参与者（Payment Gateway、Inventory System、Notification Service、Scheduler 等），每个角色记录名称（用领域语言）、描述、关键动作、权限边界，输出为角色目录。该目录直接供后续步骤使用（故事板每人类角色一条泳道、输入归属到具体角色、场景按名称引用角色、完整性校验每个角色至少有一条命令路径）。
- 识别事件流（流根）——识别将有事件流的主要实体（User/Account、Order、Payment、Shipment 等），这些并非 DDD 聚合，只是事件的逻辑根；记录名称、标识键、哪些命令会影响它。
- 识别业务过程——梳理关键工作流：用户经历哪些步骤、决策点在哪、系统在何处集成。
- 提取状态变更——对每个过程识别发生的状态变更，这些成为领域事件。
- 记录业务规则与约束——哪些规则支配状态转换、必须通过哪些校验、有哪些不变量。
- 创建分析文档——以指定结构呈现发现，包含研讨会笔记与领域分析，供
eventmodeling-designing-event-models技能直接使用。
核心架构规则
资料明确要求：状态设计绝不使用 DDD Aggregate 模式；每个命令处理器必须拥有自己从事件派生的最小状态投影，这一点不可协商。反模式示例为 OrderAggregate 被 ConfirmOrder、ShipOrder、CancelOrder、ApproveReturn 共用，问题在于加载未使用数据、耦合不相关命令；正确模式为 ConfirmOrderState、ShipOrderState、CancelOrderState 各自只加载所需字段。
关键原则
使用领域语言而非技术术语；关注发生了什么而非如何实现；以事件而非动作识别状态变更（温和引导）；记录约束与规则；结合需求给出具体示例；协作式过程而非个人分析；快速迭代、先捕获后细化；事件溯源思维，以不可变事件与流根思考，而非 DDD 聚合；推迟状态设计，不在前期列出所有实体属性；命令状态隔离，不同命令对应不同状态接口。
质量检查清单
- 每个事件均为过去时并命名一个已完成的状态变更（如 OrderPlaced 而非 PlaceOrder）
- 角色目录列出每个参与者（人类角色与系统处理器）及其明确职责
- 每个事件都可追溯到角色目录中的具体参与者
- 无 CRUD 事件（UserUpdated、RecordDeleted），事件描述业务时刻而非数据库操作
- 所有已知错误与边界条件都有对应事件
- 事件至少归入一个可识别的业务过程流
- 无重叠事件语义
使用方式与限制
资料提供的使用方式为在事件建模流程中作为第一步调用，访谈发现写入指定路径文件，最终产出 Markdown 分析文档。具体安装命令、平台支持、价格与收费信息、运行环境等资料暂未提供。