calendar-scheduling

# Calendar scheduling — booking surface + calendar sync, shipped together Scheduling is always two halves bolted together: a **booking surface** (an external person reserves a slot — embed, atom, or API call) and **calendar sync** (you read free/busy to compute availability and write the confirmed event back). Ship one without the other and you get the three bugs the rest of this skill exists to prevent: **double-booking**, **timezone drift** after a DST change, and **orphaned events** on reschedule. ## Decide the altitude first Pick the lowest-code option that still owns the data model you actually need. | You need… | Reach for | What you own | Escape hatch | |---|---|---|---| | A booking page fast, minimal code | **Embed Cal.com or Calendly** | Nothing — the widget owns slots/sync | Call the API later to read bookings / fire automation | | Bookings in *your* UI, *your* branding/data model | **Cal.com Booker atom** or **Scheduling API** (Cal.com / Calendly) | Your UI; provider owns sync | Drop to raw provider API if the data model chafes | | Read/write *one* provider's calendar directly | **Google `freebusy.query` + `events.insert`** | OAuth, refresh, slot math, watch/sync | If it's pure CRUD with no booking → `google-workspace` | | Many providers (Google + Outlook + Apple), no N integrations | **Unified API** (Cronofy or Nylas v3) | One auth/availability surface | Cronofy if cross-domain scheduling matters; Nylas v3 is domain-scoped | Why per row: the embed is zero-mai...