Google Calendar
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 google-calendar connector 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.
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.
Choose a bounded read
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.
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. The assistant-brief runner takes an exact scheduled goal occurrence, selected calendar and the calling host's actual observed_at instant with an explicit UTC offset, reads an upcoming bounded window, and returns the common operator work result. The window starts at the later of the occurrence due time and observed_at, so a wake after sleep reads the upcoming period. The host supplies this execution time; the deterministic worker never infers it from its own clock. Partial coverage holds that occurrence; it never means the calendar is free. A separate owning scheduling or conversation skill may propose times only from complete fresh 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.
