google-calendar

This is a straightforward REST wrapper in Python exposing list, add, update and delete, with JSON on stdout and non-zero exit on error, which is exactly what an agent needs from a calendar tool. The caveat is that almost all of the effort lives in setup rather than usage: you need a Google Cloud project, the Calendar API enabled, desktop OAuth credentials, and a refresh token obtained through a consent flow. Once GOOGLE_REFRESH_TOKEN and GOOGLE_CALENDAR_ID are stored, the commands are trivial, but budget for that first run. Using `openclaw secret set` for the client secret is the right call over a dotfile.

Use case: Programmatic calendar access when you already have Google OAuth credentials and want a plain REST wrapper.

# A calendar wrapper is only as good as its credential and its timezone This skill is a thin wrapper over the calendar REST interface with four operations: list, add, update, delete. Almost every failure people hit is not in the operation, it is in the credential lifecycle or in time handling. ## Store the credential outside the prompt The wrapper expects a client id, a client secret, a refresh token and a calendar id. Put them in the agent's secret store rather than in the skill invocation, so they never appear in a transcript or a log line: ```bash openclaw secret set GOOGLE_REFRESH_TOKEN openclaw secret set GOOGLE_CALENDAR_ID primary ``` The refresh token comes from an OAuth consent flow and is the piece that expires or gets revoked. When reads suddenly fail while everything else works, suspect the refresh token before suspecting the skill. ## Always pass an explicit range for reads A list call without a range returns whatever the default window is, which is rarely the window you meant. Pass the from and to values explicitly, in ISO form, so the query is reproducible. ## Make writes identifiable Events created by an agent should be recognisable as such in the title or description. When a scheduled job creates the same meeting twice because a retry ran, an identifiable event is the difference between spotting the duplicate and living with it. ## Delete by id, never by matching text Updates and deletes take an event identifier. Resolving a title to an identifier at delete time means a rename races your deletion, and the failure mode is deleting the wrong meeting. Store the identifier returned at creation if you expect to modify the event later.