google-calendar

Google Calendar

Overview

Use this skill to turn raw calendar data into clear scheduling decisions, reminder plans, and safe event updates. Keep answers grounded in exact dates, times, and calendar evidence.

Preferred Deliverables

• Availability summaries with exact candidate slots, timezone, and conflicts.
• Room or resource recommendations grounded in actual calendar availability or prior meeting patterns.
• Event change proposals that show the current event and the intended update.
• Reminder change proposals with exact lead time, scope, and the meetings that qualify.
• Temporary hold proposals or final hold details with the exact slot and whether the hold is transparent.
• Final event details that are ready to create or confirm.

Workflow

1. Read the relevant calendar state first so the request is grounded in actual events, calendars, and time windows.
2. Normalize relative time language into explicit dates, times, and timezone-aware ranges before reasoning about availability.
3. Keep reads bounded. Use explicit time_min and time_max whenever possible, avoid unbounded broad searches, and choose a small default window when the user does not state one.
4. When a bounded search returns too much, page within that same window before widening the date range. For longer historical, precedent, or preference discovery, chunk the search into smaller windows instead of one giant pull.
5. When the user leaves something ambiguous, inspect previous calendar data for a clear precedent before choosing a default. Follow established patterns when they are obvious, such as using the user's usual meeting duration if similar events are consistently 30 minutes.
6. When a participant, attendee list, manager, room, or contact detail is referenced indirectly, search a bounded relevant window and read the likely source event before asking the user for details. Use read_event or search_events_all_fields when attendee emails or full event metadata matter; the standard search_events summary is not enough for contact details.
7. If a found event belongs to a recurring series and the user wants a series-level change, read the master series or recurrence details before editing. Do not infer the cadence or scope from a single occurrence when recurring_event_id or equivalent series evidence is available.
8. Use the connector's update_event action for recurring edits and set update_scope to this_instance, entire_series, or this_and_following as needed. If the series is COUNT-based and the tool requires an explicit recurrence for a future-only split, preserve and restate the recurrence rule or explain that the connector cannot safely infer the split from one occurrence.
9. For room-finding requests, do not assume there is a reliable global room search. In this V1 flow, mine a reasonable window of past meetings, locations, and resource attendees to build a candidate room list, then compare availability on that concrete set.
10. For bulk reminder or classification-based edit requests, inspect a reasonable upcoming window first instead of asking for extra scoping immediately. If the prompt does not bound the horizon, use a narrow default such as the next 30 days and say so.
11. When notes, prep context, or missing details matter, inspect the event payload before proposing a change.
12. For free-slot and temporary-hold requests, if the prompt already gives the window and duration, search within that range and move directly to proposing or placing the hold. Prefer a transparent hold for temporary placeholders unless the user clearly wants a blocking focus block.
13. Surface conflicts, transparent holds, and missing meeting details before suggesting a write.
14. If the request is still ambiguous after checking for precedent or scanning a reasonable bounded window, summarize the candidate slots or exact diff before writing anything.