用途：在采用 Event Modeling 方法设计系统、创建事件模型，或用户提到 event modeling、commands/events/views 蓝图时使用。它产出一张整个系统的可视化蓝图——一条从左到右阅读的时间线，供开发者、设计师与干系人共享。
核心思想：事件是随时间持久化的业务事实，是唯一事实来源；用户看到的是由事件构建的视图（界面、报表），而非事件本身。
四个构建块：Trigger（白色，用例起点：UI 线框图、HTTP 端点或机器人）、Command（蓝色，改变状态的意图，含参数）、Event（橙色，持久化的业务事实，用过去时与业务语言、真实数据）、View（绿色，只读查询，为 UI、报表或自动化流程整理事件数据）。聚合、实体图、数据库模式不属于蓝图，属实现细节。
切片：最小可实施单元。一个 Command 及其 Events 为一个切片，一个 View 为一个切片，一个 Automation 或 Translation 为一个切片。
四种模式：内部模式包括 Command（Trigger→Command→Event(s)）与 View（Event(s)→View→Trigger，视图是被动的，只读取与整理，从不拒绝事件）；外部通信模式包括 Automation（我们主动触达：Event(s)→待办清单视图→机器人→Command→Event(s)，机器人只读取并调用命令，不含业务逻辑）与 Translation（外部系统通知我们：外部事件→View→翻译器→Command→我方事件）。Automation 与 Translation 的区别在于：前者是我们主动触达，后者是他们通知我们。
泳道：看板上的水平行，代表一个领域（如 Booking、Payment、Inventory）。工作坊中先按用户角色划分，再按领域/限界上下文重组并分配团队归属，可有子领域。
七步工作坊：1 头脑风暴列出所有改变状态的事件（过滤观察，如“访客浏览页面”不是事件）；2 按典型用户旅程从左到右排列事件；3 在顶部添加线框图；4 为每个线框动作添加 Command；5 为每个展示数据的屏幕添加 View；6 按领域重组泳道并分配团队；7 为每个切片编写规格。
规格：每个切片都有契约。Command 用 Given（前置事件）→When（命令）→Then（产生事件）；View 用 Given（累积事件）→Then（查询结果）；Automation 用 Given（待办行）→When（机器人调用命令）→Then（产生事件、行消失）。前置条件不满足则命令被拒绝；失败事件可选，仅在系统需要对其反应时单独建模。
完整性检查：每个 UI 字段可追溯到事件或视图；每个命令有含真实数据的 Given-When-Then；每个视图有 Given-Then；每个自动化有具名待办视图、具名机器人与产生的命令；无孤立事件。
输出：使用 references/output-template.md 生成事件模型文档，含面向不熟悉该记法的干系人的导读。参考文件包括 output-template.md 与 event-model-example.md（酒店预订完整示例，5 条泳道 18 个切片）。
常见错误：把观察当事件；跳过线框图直接写事件；使用 DDD 聚合或实体图；在机器人中放业务逻辑；让视图校验或拒绝；规格缺少真实数据；混淆 Automation 与 Translation；在 Automation 切片写 Trigger 段；待办视图缺少填充/移除逻辑。
外部参考：https://eventmodeling.org/posts/what-is-event-modeling/ 与 https://eventmodeling.org/posts/event-modeling-cheatsheet/。
限制：资料未提供该技能的安装命令、收费方式、支持平台与运行环境等信息。