--- name: busycal-schedule-week-review description: Read-only review of the coming week in BusyCal, surfacing conflicts, overloaded days, undated or overdue tasks and gaps worth protecting, and reporting what needs attention without changing anything. Use when the user asks what their week looks like, wants a weekly review, asks what needs attention this week, or wants to spot clashes and overload before planning. --- # Review the coming week in BusyCal The goal is a short, honest picture of the week: where it is overbooked, where it is fragile, and what has slipped. This is a review, not a planning session. Nothing is moved, completed or created. If the user wants changes, hand over the findings and let them decide which job to run next. ## 1. Confirm scope before reading anything Start with `list_accounts` and `list_calendars`. Decide which calendars count as "the week". Work calendars and personal calendars often need separate treatment, and some calendars may be shared or subscribed and not the user's to act on. Ask the user once if it is unclear, then state the scope you used in the report. Check the date window. "This week" means the user's local week as they describe it. Confirm the start day and whether the weekend matters. Note the current date so overdue items are measured against it. If the BusyCal app is not running, the tools may launch it. Say so in the report if that happened, and do not treat a slow first response as an error. ## 2. Pull events, then tasks, then availability Read in this order so each step narrows the next: 1. **Events** with `query_events` over the window, limited to the chosen calendars. Note each event's start, end, all-day status and calendar. 2. **Tasks** with `query_tasks`. Pull due-dated tasks in the window, plus overdue ones and undated ones separately. Tasks carry duration and priority, so use them when judging load. 3. **Free time** with `query_availability` for the window, filtered to working hours. This shows where the gaps are, which is more useful than counting events. Page through results rather than requesting everything at once. For a busy calendar, summarise by day and drill into a single day only where a problem appears. Do not paste long item lists into the reply. If `selected_items` returns something, it reflects the user's current on-screen selection and may not be part of the week at all. Mention it only if the user had clearly selected items for this review. ## 3. Classify what you found Sort findings into these buckets. A finding belongs in exactly one bucket, and the most serious bucket wins. - **Conflicts.** Two or more timed events overlapping on the same calendar or across calendars the user treats as one schedule. Overlaps between a personal and a work calendar are worth flagging but may be intentional; label them as such. - **Tight transitions.** Back-to-back events with no gap, or a gap shorter than the travel time recorded on the event. Check travel time on the event itself; do not assume it. - **Overloaded days.** Use a simple threshold: more than about six hours of timed events, or no free block of 60 minutes between the first and last commitment. Say which threshold you used. - **Overdue tasks.** Due before today and not complete. Group by age (this week's overdue, older than a week) rather than listing each one. - **Undated tasks.** Tasks with no due date that look like they belong in this week, judged by their title, calendar or priority. Be cautious: many undated tasks are backlog and are not a problem. - **Protect candidates.** Free blocks of 90 minutes or more during working hours that are not already claimed, especially around high-priority tasks that have no time allocated. ## 4. Check for what is missing The useful findings are often absences. Look for: - A high-priority task due this week with no free block before its due date to work on it. - A day with events but no travel time recorded where the locations clearly differ. - A recurring commitment that appears to have dropped out of this week. - A calendar that returned no events at all when the user normally has some. Report it as possibly empty or unreadable, not as proof of a free week. ## 5. Keep the tone plain and the claims bounded State what you saw, not what the user should feel about it. "Tuesday has five meetings totalling 6.5 hours with no free hour" is useful; "Tuesday is too busy" is opinion. Where a result looks odd, such as a calendar with no events, say that you cannot tell whether it is correct and what would confirm it. ## Common patterns and traps - **Counting events instead of time.** Five 15-minute check-ins are lighter than two 2-hour workshops. Judge load by hours and gaps. - **Treating all-day events as blocking.** An all-day "Out of office" or "Public holiday" changes the day's capacity but is not a meeting clash. Report it as context. - **Flagging every undated task.** Most undated tasks are backlog. Surface only the few that match this week's themes or high priority. - **Overlap that is intentional.** Tentative holds, optional invites and personal events placed over work blocks are often deliberate. Label them, do not call them errors. - **Shared or subscribed calendars.** The user may not control them. Mention clashes with them as information only. - **Empty results read as free time.** A failed or restricted read looks identical to an empty week. Check the calendar list before claiming a week is open. - **Time zones.** Events entered in another zone can appear to clash or shift. If a conflict depends on zone, say so. ## Output ``` Week: to , calendars read: Overall: Conflicts () -