calendar-sync

name	calendar-sync
description	Reconstructs a day's work from git commit history in the current repo, groups it into time-blocked calendar events (merged by feature/goal, minimum 20 minutes each), and writes them to that repo's mapped Google Calendar — creating new events or updating existing overlapping ones so reruns stay idempotent. Replaces the old hook-based time-tracking system. Use when the user wants to log/sync their day's work to their calendar, review what they did today, or backfill a prior day. Triggered by '/calendar-sync', 'sync my calendar', 'log today's work to calendar', 'daily lookback', 'what did I work on today'.
allowed-tools	["Bash(git log:*)","Bash(git rev-parse:*)","Bash(cat:*)","Bash(gws:*)","Read","ToolSearch","mcp__claude-in-chrome__tabs_context_mcp","mcp__claude-in-chrome__tabs_create_mcp","mcp__claude-in-chrome__navigate","mcp__claude-in-chrome__computer","mcp__claude-in-chrome__find","mcp__claude-in-chrome__get_page_text","mcp__claude-in-chrome__browser_batch"]
argument-hint	[date or date range, default: today]
context	fork

Calendar Sync

Turns a repo's git commit history for a given day into time-blocked events on that repo's own Google Calendar. Fully autonomous — no approval gate, full CRUD freedom on the target calendar once it's correctly resolved.

Inputs

• $ARGUMENTS: Optional date or date range to sync (e.g. "yesterday", "2026-07-10", "2026-07-08 to 2026-07-10"). Defaults to today if omitted.

Goal

Every distinct chunk of work done in the repo during the target date range has exactly one correctly-timed, correctly-titled, >=20-minute event on the repo's mapped calendar — with no duplicates and no events left on the wrong (personal primary) calendar.

Steps

1. Resolve scope and date range

Determine the repo root (git rev-parse --show-toplevel from cwd) and parse $ARGUMENTS into a concrete start/end timestamp range, defaulting to today 00:00–23:59 in the user's local timezone.

Success criteria: repo root path and a concrete [start, end] timestamp range.

2. Resolve the target calendar (do not default to primary)

Read ~/Desktop/Valor/projects.json, match the repo root against each project's working_directory to find the project slug (e.g. cyndra-consulting → cyndra). Read ~/Desktop/Valor/calendar_config.json's calendars map and look up that slug to get the Google Calendar ID. Fall back to the map's "default" entry only if no project match is found.

Rules:

• Never silently fall back to the personal primary/"Valor Engels" calendar for a repo that has its own mapped calendar — that was the mistake made the first time this process ran manually.
• This mapping data is reused as-is from the existing config; do not read or reimplement the old .calendar_hook_* hook logic in that same directory — this skill replaces it.

Success criteria: a resolved Google Calendar ID that is not the personal primary calendar unless the project's mapping explicitly says "primary"/"dm".

3. Gather commit history

Run git log scoped to the resolved date range in the repo root (subjects, bodies, and timestamps — --since/--until, --date=format:'%Y-%m-%d %H:%M').

Artifacts: chronological list of {timestamp, subject, body} commits for the range.

Success criteria: full commit list for the range captured, nothing missed at the range boundaries.

4. Group commits into events

Cluster commits that share a common feature/goal (same issue number, plan doc, subsystem, or PR) into a single event rather than one event per commit. Title each event with the feature/end-user goal, not a literal commit subject; the description summarizes the underlying commits.

Rules:

• Every event must be at least 20 minutes long. If a natural cluster's span is shorter, extend it (merge into an adjacent same-feature cluster, or pad up to the 20-minute floor) rather than leaving a sub-20-minute event.
• Events must not overlap.

Success criteria: ordered list of {title, start, end, description} events, each >=20 minutes, non-overlapping, covering the day's real work.

5. Resolve the write tool

Try in order: (a) gws calendar if gws auth status shows valid credentials — target the calendar ID from step 2 directly; (b) a Calendar MCP tool if one is loaded for this session; (c) browser automation on calendar.google.com as the last resort, using the render?action=TEMPLATE&text=&dates=&details= prefill URL.

Rules:

• On tier (c), the prefilled event editor defaults to the personal primary calendar — you must switch the calendar dropdown to the resolved project calendar (step 2) before saving every single event.
• On tier (c), do not batch "click Save" immediately followed by "navigate to the next event" in one call — Google Calendar's editor blocks navigation with a "Leave site?" dialog if the save hasn't visually completed. Click Save, screenshot to confirm the URL dropped /eventedit, then navigate to the next event.

Success criteria: a working write path confirmed (auth valid, or tool present and responsive).

6. Deduplicate against existing events

Read events already on the resolved calendar for the date range. For each proposed event from step 4 that time-overlaps an existing event, update that existing event's title/time/description in place instead of creating a new one. Only create net-new events for time slots with nothing existing.

Success criteria: no duplicate or overlapping events remain on the calendar after this run, including on reruns for the same day.

7. Create/update events

Execute the writes (creates and in-place updates) via the tier resolved in step 5.

Success criteria: every event from step 4 exists on the resolved calendar exactly once, correctly timed/titled/described.

8. Verify

Re-fetch the calendar's day view (API read or day-view screenshot) for the resolved calendar and date range.

Success criteria: every proposed event is visibly present, non-overlapping, and correctly timed; report a short summary back to the user.

Notes for the future scheduled version

A later daily cron-scheduled variant of this will also ingest local machine activity alongside git commits as an input to step 4's grouping. Keep step 3 ("gather commit history") as a swappable input-gathering step rather than hardcoding git as the only source, so that addition slots in cleanly.