calendar (v4)

CRITICAL — 开始前 MUST 先用 Read 工具读取 ../lark-shared/SKILL.md，其中包含认证、权限处理 CRITICAL — 所有的 Shortcuts 在执行之前，务必先使用 Read 工具读取其对应的说明文档，禁止直接盲目调用命令。 CRITICAL — 凡涉及【预约日程/会议】或【查询/搜索会议室】，第一步 MUST 强制使用 Read 工具读取 references/lark-calendar-schedule-meeting.md。禁止跳过此步直接调用 API 或 Shortcut！ CRITICAL — 术语约束：用户日常表达中常说的“帮我约个日历”、“查一下今天的日历”等，其实际意图通常是针对 日程（Event） 的创建或查询，而非操作 日历（Calendar） 容器本身。请自动将口语化的“日历”意图映射为“日程”操作（如 +create, +agenda）。 CRITICAL — 会议与日程的意图路由：

• 查询过去时间的会议：如果用户明确查询过去时间的会议（如“昨天的会议”、“上周的会议”），优先使用 ../lark-vc/SKILL.md 搜索会议记录。因为会议数据不仅包含从日程发起的视频会议，还包含即时会议，仅查询日程数据会导致结果不全。
• 查询日历/日程或未来时间的会议：如果用户明确表达的是“日历”、“日程”，或者涉及未来时间的安排，则属于本技能（lark-calendar）的业务域，请继续使用本技能处理。 CRITICAL — 任务类型分流：处理“预约/改约日程、添加/移除参会人、添加/更换会议室、调整时间”时，必须先判断用户是在“新建日程”还是“编辑已有日程”。
• 编辑已有日程的强信号：用户明确提到某个已存在的日程锚点（如标题、时间段、这个日程、这场会）并表达修改动作（如“添加”“移除”“改到”“换会议室”“调整时间”）。这类请求默认走编辑已有日程，绝不能直接按新建处理。
• 编辑已有日程的前置步骤：一旦判定为编辑，MUST 先定位目标日程或具体实例的 event_id，再继续后续流程。若是重复性日程，MUST 先定位到对应实例的 event_id。
• 新建日程：只有当用户表达的是“新约一个会/创建一个日程/安排一次会议”等新增意图，且没有指向某个既有日程的修改动作时，才进入新建流程。

CRITICAL — 验证与同步延迟：在涉及删除日程（delete）、修改日程（patch）或者涉及添加移除参与人/会议室之后，如果需要进行二次查询验证操作结果，MUST 等待至少 2 秒后再进行查询，以防止因数据同步延迟导致查不到最新数据。注意：不要向用户提及你等待了这 2 秒钟的事情。

CRITICAL — 重复性日程的实例操作：目前已经完全具备对重复性日程的某个具体实例进行操作的能力（例如：编辑某个实例、删除某个实例、为某个实例添加/删除参与人、为某个实例添加/移除会议室）。只要在对应的操作中传递对应实例的 event_id 即可。因此，MUST 先定位到对应的那次实例的 event_id（可通过 events search_event 搜索日程，或 +agenda 查看对应时间范围的日程等相关查询获取），绝对禁止直接使用原重复性日程的 event_id 进行操作。

时间与日期推断规范：