Calendly

要解决的问题

把 Calendly 塞进自动化工作流，难点通常不在单个 API，而在凭据管理、连接状态和对象路由。手写 HTTP 客户端要自己处理 token 刷新、scope 缺失、连接过期，还要为日程、预约、参会者、组织、Webhook、路由表单等十几类对象各写一套请求。这个技能把这些细节收进 oo CLI 与 OOMOL 连接器：凭据由服务端注入，客户端只面对一套稳定的 action 契约。

核心能力

它围绕 Calendly 的数据模型展开，共提供 37 个 action，大致分四类：

• 日程与预约：list_scheduled_events、get_scheduled_event、cancel_scheduled_event、create_event_invitee、list_event_invitees、get_event_invitee
• 事件类型与可用性：list_event_types、get_event_type、list_event_type_available_times（7 天窗口）、list_user_busy_times、update_event_type_availability_schedule、list_user_meeting_locations
• 组织与成员：get_organization、list_organization_memberships、create_organization_invitation、revoke_organization_invitation
• 路由表单与 Webhook：list_routing_forms、get_routing_form_submission、create_webhook_subscription、list_webhook_subscriptions

还有几类单点能力：一次性调度链接（create_single_use_scheduling_link）、定制分享链接（create_share）、no-show 标记（create_invitee_no_show / delete_invitee_no_show）。

运行流程

每个 action 的调用流程是固定的。先用 oo connector schema 拉取权威的输入/输出契约，别靠猜字段名；再用 --data 传 JSON payload，可以是对象字符串或 @path/to/file.json。响应统一为 { "data": ..., "meta": { "executionId": "..." } }，执行 ID 从 meta.executionId 取。

安全模型很明确：get / list 这类读操作可以直接跑；create / update 会改变 Calendly 状态，运行前要和用户确认 payload 与影响；delete 是破坏性操作，必须先确认目标并拿到明确批准。凭据、认证、连接都由 OOMOL 服务端注入，本地不碰原始 token，也不主动触发登录或连接流程，只有在命令真的报认证或连接错误时才走一次性设置。

适用边界

它覆盖的是 Calendly 官方数据面：日程、预约、组织、路由表单、Webhook。它不是通用浏览器自动化，也不处理 Stripe 计费、邮件发送等外围系统。单次 action 同步返回，长跑批处理要自己控节奏。7 天窗口类查询（可用时间、忙时）是硬边界，别指望拿它做跨周排期。