google-calendar

Files (8)

• SKILL.md
• composes-in-graph.yaml · fixtures/
• default-requires-binding.yaml · fixtures/
• default-runs-events.yaml · fixtures/
• composed.graph · fixtures/support/
• google-calendar.mjs
• catalog.md · references/
• run.yaml

SKILL.md (first lines)

# 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.

From runxhq/runx, Apache-2.0.

More from runxhq/runx