--- name: reclaim-ai-schedule-review description: Read a Reclaim.ai calendar for a day or week and report load, conflicts, free windows and at-risk work, without changing anything. Use when the user asks what their day or week looks like, how busy they are, where the gaps are, whether there are conflicts, or wants a calendar overview before planning or scheduling. --- # Review a schedule This is the read-only overview. Its job is to give an accurate picture of the time ahead so the user can decide what to do next. It does not fix anything. Most other scheduling jobs begin from a review like this, so keep the output tight and factual, and separate what is on the calendar from what is inferred. ## 1. Confirm the window and the account Before reading, pin down exactly what the user means. "This week" in Monday-start or Sunday-start terms, "tomorrow" in the user's timezone, and whether weekends count. If the user has several calendars or accounts available, state which one you are reading. Do not switch accounts or workspaces to answer a question; if the needed calendar is not the active one, say so and ask. Switching the active account or workspace needs the user's explicit yes. ## 2. Pull the schedule, then the details that matter Start with `get_schedule` for the window. This gives the broad shape: events, blocks and open time. Only then call `get_event_details` for events whose nature you cannot judge from the summary, such as a meeting that might be a recurring 1:1, an all-day event, or something with a large attendee list. Do not fetch details for every item; that floods the context and adds little. If you need to know whether a slot is genuinely open rather than just unlabelled, use `find_open_time` for that window instead of inferring freedom from gaps. For how much is at risk, `get_at_risk_tasks` shows work that will not fit in the time available. Read it alongside the calendar, because at-risk work is the most useful thing to surface in a review. ## 3. Measure load in hours, not impressions Compute the numbers before describing them: - **Meeting hours** per day and for the window, summed from event durations. Note how many of those hours are in the same day as the user's peak. - **Longest uninterrupted free block** per day. Under about 90 minutes, a day is fragmented, even if the total free time looks fine. - **Back-to-back runs.** Three or more meetings with no gap is a load signal worth naming. - **Start and end times** outside the user's working hours, if the preferences you can see make that clear. If you cannot see working hours, say that you did not check them. Give totals as hours and minutes. Round sensibly and say when a number is an estimate. ## 4. Spot conflicts and problems, and say which kind Look for three things and label them separately: - **Hard conflicts:** two events overlapping at the same time. - **Soft conflicts:** back-to-back meetings with no travel or buffer, or a focus block booked over by a meeting. - **Missing items:** a meeting with no video link where one is expected, or an invite the user has not responded to. Only report these if the details actually show them. Do not declare a conflict on the basis of a guess about travel time or time zones you cannot verify. ## 5. Report what is at risk and what is open End with the forward-looking part: the free windows that could absorb work, and the tasks that will not fit. Be concrete about the window ("Tuesday 14:00 to 15:30 is open"), and say how confident you are that it is actually free. If you only inferred it from the absence of events, say so. ## Common patterns and traps - **Mistaking a crowded calendar for a busy day.** Ten short syncs can be lighter than two long meetings. Judge by meeting hours and fragmentation, not event count. - **Treating an all-day block as a commitment.** Out-of-office, focus holds and reminders may appear as events. Name them as such rather than counting them as meetings. - **Counting "free" time that is not usable.** A 40-minute gap between two meetings is not a work block. Apply the 90-minute rule before calling time free. - **Going quiet on what you did not check.** If you read the schedule but not the preferences or the task list, the review is incomplete. Say which parts were covered. - **Drifting into fixing.** A review that starts proposing moves has changed job. Note the issue, offer the next step, and wait. ## Output ``` Window: Load: , busiest day at Fragmentation: Conflicts: , Free windows: At risk: Not checked: ``` ## Rules - Do not create, move, cancel, accept, decline or reschedule anything during a review. Read-only only. If the user wants a change, state what you would change and wait for the user's explicit yes before any tool that writes. - Do not switch the active account or workspace without the user's explicit yes. - Never present an inferred free slot as confirmed free. Say how it was determined. - Never present the review as complete when a part of the window or a source was not read. ## Done when - The window and calendar read are stated, and the load is given in hours and minutes. - Conflicts are labelled hard or soft, and free windows carry a confidence level. - Nothing has been changed, and the "Not checked" line is honest.