---
name: booking-desk-event
description: Use when processing hotel booking desk emails, attachments, images, PDFs, spreadsheets, OCR, or message threads to identify reservation operation events and preserve unhandled current business intents for display, including New Booking, Update Booking, Cancel Booking, Voucher Received, Payment Evidence, Rooming List, Amend Group Code, Trace or Reservation Notes, TA Recorder, Invoice, Allotment or Control Block, and Need Manual Review. Outputs candidate MessageEvents and display metadata only; does not create TaskCards or write Opera/PMS.
---

# 预订部业务事件识别

## 1. 业务目的

用本 skill 读取已经整理好的当前邮件素材包，判断这封邮件里有哪些预订部业务事件。

它处理的不是一个固定任务类型，而是一封邮件可能带来的完整预订部动作和补充业务信息：新订、改单、取消、付款凭证、名单、改团号、Trace、TA Recorder、发票、控房/配额，以及无法安全处理时的人工复核。与具体预订对象相关的补充事实即使只是告知，也可以生成 Trace；意图清楚但现有任务类型无法承接的其他当前内容必须通过邮件级展示字段保留。

本 skill 只输出候选 `MessageEvent`、未覆盖当前意图展示信息、候选目标 key、抽取字段、证据和结构化人工复核原因。它不创建真实 TaskCard，不写 Opera/PMS，不确认 Payment，不更新 Reservation Type，不生成 Invoice 或 Receipt。

## 2. 输入素材

期望 Main Agent 提供：

- `source_message`
- `body_current`
- 当前附件、图片、PDF、Excel、OCR、表格和文件链接摘要
- 合法取得的 `body_thread_evidence`
- 历史查询摘要，如适用
- 信息系统上下文摘要，如适用
- Main Agent 已能安全预拆的事件边界
- `unknowns` 中由 Main Agent 保留的未覆盖当前业务内容
- 不可读证据和冲突点

`source_message.source_message_id` 必须来自上游且为非空值；不得猜测。Main Agent 应在正文、附件和历史处理前先保存 source message identity。

Main Agent 只有在 `candidate_events` 已匹配至少一个支持业务事件时才调用本 skill。已匹配支持事件但 current 证据不足、目标不清或 current/history 边界不清时，不要猜，输出 `Need Manual Review`。输入可理解但没有匹配支持事件时由 Main Agent 输出 `S10`；输入不足、无法判断是否匹配支持事件时由 Main Agent 输出 `S99`。

## 3. 处理流程

1. 读取 `references/00-output-contract.md`，确认输出结构。
2. 读取 `references/01-current-history-boundary.md`，确认 current 与历史证据边界。
3. 读取 `references/03-current-content-completeness.md`，确认当前内容没有被事件路由静默丢弃。
4. 读取 `references/02-event-routing-map.md`，选择候选业务事件。
5. 按事件类型读取 10-18 业务事件 references。
6. 涉及供应商表格、控房配额、房型、Rate Code、Fix Charge、手工价格或 stay date parsing 时，读取 30-54 规则 references。
7. 如果不能安全输出普通候选事件，读取 `references/90-manual-review.md` 并输出结构化人工复核。

## 4. Reference 分区

基础契约：

- `00-output-contract.md`
- `01-current-history-boundary.md`
- `02-event-routing-map.md`
- `03-current-content-completeness.md`

业务事件：

- `10-new-booking.md`
- `11-update-booking.md`
- `12-cancel-booking.md`
- `13-voucher-payment.md`
- `14-rooming-list.md`
- `15-amend-group-code.md`
- `16-trace-notes.md`
- `17-ta-recorder-note.md`
- `18-invoice.md`

供应商和业务对象场景：

- `30-qbd-liantai-workflow.md`
- `31-allotment-control-block.md`

共享规则：

- `50-room-type-mapping.md`
- `51-rate-code.md`
- `52-fix-charge.md`
- `53-manual-rate-code.md`
- `54-stay-date-parsing.md`

异常和人工复核：

- `90-manual-review.md`

## 5. 硬边界

- 只有当前邮件证据能触发新的业务事件。
- 历史只能绑定目标、旧值或上下文，不能单独触发普通业务。
- 一个事件只承载一个目标对象；同一目标可以同时有主事件和一个按目标合并后的 linked Trace。
- 一个 QBD/LianTai 当前有效行一个事件。
- 不得把多个 `group_code` 合并到一个事件。
- Voucher 必须有当前图片、PDF 或文件证据。
- Rooming List 必须能证明是名单，不得把 booking update 表当名单。
- Extra bed 是 Trace / Guest Request，不是房量，不是房型，不决定 Rate Code。
- Meeting、meal、arrival notice、room preference/setup、已确定的 payment information 或其他具体预订补充信息，即使只是告知，也按目标生成 Trace；普通补充信息不输出 `Note`。
- 同一封邮件、同一目标对象的多条补充信息合并成一个 Trace；多个目标对象分别生成 Trace。
- 主任务已经完整承接的核心参数不得重复生成 Trace。
- `notify_departments` 不清时使用空数组，不得仅因此输出人工复核。
- 需要酒店批准的价格、退款、账期、付款政策或合同条件询问不是 Trace，且不得静默忽略。
- 当素材包同时包含支持事件和 `unknowns[].category=unhandled_current_business_content` 时，普通事件或人工复核照常输出，并把每个 unknown 一对一规范化到顶层 `unhandled_current_intents`。
- `unhandled_current_intents` 只承载意图清楚但当前不支持的业务内容；它不是事件，不得创建任务，也不得与 `extraction_warnings` 混用。
- 房型和 Rate Code 必须由 reference 唯一支持；不唯一就人工复核或下游硬校验。
- 素材包已经匹配支持业务事件但业务判断不安全时输出 `Need Manual Review`；`S10` 和 `S99` 都属于 Main Agent 入口结果，不由本 skill 输出。
- 本 skill 只判断候选业务事件，不替用户决定是否回复邮件或进行其他非预订沟通。
- 不输出真实 TaskCard ID、最终 Case 裁决、执行状态、Payment 确认、Block Status 转换、Receipt 或 Opera/PMS 写入结果。

## 6. 输出

将以下结构化 JSON 参数对象作为调用结果直接返回给 Main Agent：

```json
{
  "source_message": {
    "source_message_id": "<required>"
  },
  "message_events": [],
  "case_candidates": [],
  "extraction_warnings": [],
  "unhandled_current_intents": []
}
```

该结果是内存中的参数对象，不是 JSON 字符串或文件产物。根对象必须直接使用上述结构，不得增加 `booking_data`、`file`、`filename`、`artifact`、`download_url` 或其他文件包装层。

不得创建、写入、上传、附加或返回 `.json` 结果文件，不得用结果文件名、文件路径、下载链接、artifact 或文件引用代替该对象，不得使用 Markdown 代码块包装最终返回值，也不得增加 `output_mode`、`filename` 等交付控制字段。

以上限制不影响输入附件处理。事件中的 `attachments` 和 `file_references` 可以继续保存 Excel、PDF、图片等输入证据，但不能替代最终 JSON 参数对象。

每个事件必须包含：

- `event_type`
- `event_role`
- `current_or_history`
- `source_event_index`
- `case_keys`
- `relevant_message_excerpt`
- `attachments` 或 `file_references`
- `context_used`
- `extracted_fields`
- `manual_review`，如需要

## 7. 判断原则

能安全拆分就拆分，不能安全拆分就人工复核。

能输出普通候选事件的前提是：当前动作明确、目标绑定明确、必要证据可读、业务 reference 支持、系统上下文没有明显阻塞。

输出前必须执行内容完整性检查：每项有业务意义的当前内容已经进入普通事件、业务人工复核或 `unhandled_current_intents`；不得仅因原文仍可在源邮件中查看而省略未覆盖意图。

人工复核也是有效业务结果。必须写清原因、缺失字段、冲突点、需要人工查看的证据和已确认字段。
