lark-calendar

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 — 会议与日程的意图路由： CRITICAL — 验证与同步延迟：在涉及删除日程（delete）、修改日程（patch）或者涉及添加移除参与人/会议室之后，如果需要进行二次查询验证操作结果，MUST 等待至少 2 秒后再进行查询，以防止因数据同步延迟导致查不到最新数据。注意：不要向用户提及你等待了这 2 秒钟的事情。 CRITICAL — 重复性日程的实例操作：目前已经完全具备对重复性日程的某个具体实例进行操作的能力（例如：编辑某个实例、删除某个实例、为某个实例添加/删除参与人、为某个实例添加/移除会议室）。只要在对应的操作中传递对应实例的 event_id 即可。因此，MUST 先定位到对应的那次实例的 event_id （可通过 events search_event 搜索日程，或 +agenda 查看对应时间范围的日程等相关查询获取），绝对禁止直接使用原重复性日程的 event_id 进行操作。 时间与日期推断规范： 为确保准确性，在涉及时间推断时，请严格遵循以下规则： BLOCKING REQUIREMENT (阻塞性要求): 只要用户的意图包含“预约日程/会议”或“查询/搜索可用会议室”，你必须立即停止其他思考，优先使用 Read 工具完整读取 references/lark-calendar-schedule-meeting.md ！未读取该文件前，绝对禁止执行任何日程创建或会议室查询操作。 CRITICAL: 必须严格按照上述文档中定义的工作流（Workflow）执行后续操作。处理该场景时，默认做“智能助理”，不要做“表单填写机”。能补全的默认值先补全，只有在时间冲突、结果无法唯一确定、时间语义存在歧义时才主动追问。 CRITICAL: 执行顺序必须固定为：先判断任务类型（新建/编辑）；若为编辑先定位目标日程 event_id ；再补默认值或继承已定位日程的已知信息；再判断时间是否明确；最后进入“明确时间”或“模糊时间/无时间信息”分支。不要跳步。 CRITICAL: 明确时间且需要会议室时，先基于最终确定的时间块执行 +room-find ，再按需执行 +freebusy ；模糊时间或无时间信息时，先 +suggestion ，如需会议室再批量 +room-find...