用途：以 Fran Méndez 的 AsyncAPI 哲学设计事件驱动架构，把消息契约当作与 HTTP 请求同等重要的资产，先定义规范再实现代码，避免异步系统中的“隐藏知识”。
主要能力：提供两类提示词模板。一是设计事件驱动系统，要求先产出完整的 AsyncAPI 3.0 定义，关注通道逻辑命名（如 user/signedup，而非 user-signedup-queue-prod）、消息头与载荷分离、用 operation traits 复用通用绑定（如 Kafka 分区键）、促进服务间松耦合。二是审计既有消息系统，检查仅存在于代码或字符串中的隐式 Schema、泄漏生产者实现细节的紧耦合、缺少 correlation ID 或时间戳等元数据、以及难以路由的模糊通道层级。
核心原则：Event First（规范即架构）、Channel-Centric Design（聚焦主题/队列及流经的消息）、Protocol Agnostic（同一设计可运行于 Kafka、MQTT、RabbitMQ 或 WebSockets）、Schema Governance（跨消息复用载荷 Schema）、Documentation as Infrastructure（AsyncAPI 文件同时是代码生成器、校验器和 mock 的配置）。
使用方式：在提示词中指定系统名称，要求以 AsyncAPI 3.0 输出通道、消息、traits 与解耦设计；审计时提供现有事件结构，按隐式 Schema、紧耦合、缺失元数据、模糊通道四类问题排查。示例契约展示 channels、operations、components（messages、schemas、messageTraits）的组织方式，头部含 correlationId 与 timestamp，载荷引用 GeoCoordinates。
反模式：Code-First 事件（用 Map<String,Object> 或 interface{} 序列化）、包含所有字段的“上帝事件”、把 event_time 或 trace_id 放进载荷而非协议头、把 RabbitMQ exchange 名硬编码进应用逻辑。
限制：资料未提供具体安装命令、收费方式、平台支持范围或效果数据，暂未提供。