google-calendar ยท diff

git:20261004.6f77bf7 to git:20261004.794bd58

17 added, 5 removed. Audit A to A.

---
name: google-calendar
description: Read a selected Google Calendar's bounded events or free/busy window through a governed connection, preserving coverage and time semantics for downstream planning.
---
# Google Calendar
- Use this skill when a decision needs current events or busy intervals from a calendar the operator has explicitly selected. The default `events` runner reads expanded event instances over a window of at most 30 days. `freebusy` reads one selected calendar's busy intervals. Both use the native `provider.read` boundary, an exact calendar target and the least-privilege Google OAuth scope; neither can write, RSVP or invite anyone.
+ Use this skill when a decision needs current events or busy intervals from a Google calendar the operator has explicitly selected. The default `events` runner reads expanded event instances; `freebusy` reads only busy intervals. Both are read-only native `provider.read` operations with an exact calendar target and a window no longer than 30 days. They cannot create, edit, delete, RSVP to, or invite anyone to events.
- Connect the intended Google account to `google-calendar` with `events.read` and/or `freebusy.read`. An Analytics or Search Console connection does not grant Calendar access. Supply the exact calendar ID and offset-bearing start/end instants. `primary` means the connected account's primary calendar. For multiple calendars, call the runner separately for each selected ID and keep each result's coverage. A read failure, a provider error or an incomplete event page means unknown coverage, not a free slot.
+ The portable skill owns Calendar evidence semantics, not credentials or connector selection. A local, self-hosted, third-party, or Runx-hosted connector is compatible when it implements the declared operations and scopes. Keep connection identifiers, credentials, tenant details and private calendar choices in the operator's binding and inputs, never in this package.
- The returned `calendar_context` preserves source status, selected target, window, observation time, expanded recurring-instance identity, all-day dates and their exclusive end, cancellation, transparency, self-response and busy intervals. Private event titles are removed. A `partial` or `blocked` decision cannot establish availability. Event absence is meaningful only with complete coverage. Refresh evidence before proposing a meeting time; the assistant may use it for preparation and attention timing. `chief-of-staff` owns any scheduling or reply proposal using this packet plus bounded mail context. It must derive available slots from complete fresh evidence and working-hour policy; this skill does not offer slots or send messages.
+ ## Choose a bounded read
- `normalize-supplied` accepts already collected readback for composition without another provider call. Its output says `supplied_result` and `not_called`; only the prior receipt can attest where those bytes came from. Keep that receipt reference with downstream work. Do not use an unverified supplied packet as proof of a live Google read. A new live read uses `events` or `freebusy`. No sync-token store, mirrored event database, webhook loop or calendar mutation lives here.
+ Authorize the intended Google account for `events.read` and/or `freebusy.read`. The hosted Google binding requests `calendar.events.readonly` for event details and `calendar.events.freebusy` for busy-only reads; Analytics or Search Console access does not grant Calendar access. Supply the exact calendar ID plus start and end instants with explicit UTC offsets. `primary` selects the connected account's primary calendar. For multiple calendars, run the selected IDs separately and preserve each result's coverage.
- Example: run `events` for `primary`, `2026-10-04T00:00:00+11:00` through `2026-10-11T00:00:00+11:00`; feed the resulting context and its receipt to the assistant. If the result is partial, retry the same bounded window before declaring the calendar clear. If the goal is to create or move an event, use a separately governed future mutation capability; this read-only skill must stop.
+ The `events` runner expands recurrence within the selected window and has a finite page budget. Use `freebusy` when only availability is relevant, so event titles are not collected. A live runner returns provider readback; `normalize-supplied` only normalizes already collected bytes and says `supplied_result`/`not_called`. Keep the prior receipt with that packet if it is to be treated as prior provider evidence.
+
+ ## Interpret the evidence
+
+ The returned `calendar_context` binds calendar ID, window, observation time, recurrence and cancellation identity, all-day dates with exclusive end, transparency, self-response and busy intervals. Private event titles are removed. An inaccessible calendar, provider error, stale result or incomplete event page means unknown coverage, never a free slot. Event absence establishes nothing unless every selected calendar window is complete and fresh. An all-day event covers local dates through the day before its exclusive end; do not turn it into a guessed UTC meeting time. A cancelled recurring instance is not a live commitment.
+
+ The assistant may use complete current evidence for meeting preparation and attention timing. `chief-of-staff` owns any scheduling or reply proposal using this packet plus bounded mailbox context. It must derive candidate slots from complete fresh calendar coverage and private working-hour/buffer policy. This skill neither offers slots nor sends messages. Event mutations belong to a separately governed future capability.
+
+ ## Recover and compose
+
+ If a page cap makes an event window partial, narrow the requested window into disjoint smaller windows, read them under the same selected calendar authority, and merge only complete slices by event instance identity. Repeating the same capped query cannot prove completeness. If a provider error or expired grant caused the gap, repair the binding and refresh the affected window. Do not add a mirrored event database, sync-token store, webhook loop or assistant-owned case for routine polling.
+
+ For example, read `primary` from `2026-10-04T00:00:00+11:00` through `2026-10-11T00:00:00+11:00`, then pass the context and receipt to the assistant. If that read is partial, split the week into smaller bounded reads before concluding there are no other commitments.