email-to-calendar

CRITICAL RULES - READ BEFORE PROCESSING ANY EMAIL

1. NEVER CALL gog DIRECTLY - ALWAYS use wrapper scripts (create_event.sh, email_read.sh, etc.). Direct gog calls bypass tracking and cause duplicates. THIS IS NON-NEGOTIABLE.
2. IGNORE CALENDAR NOTIFICATIONS - DO NOT process emails from [email protected] (Accepted:, Declined:, Tentative:, etc.). These are responses to existing invites, NOT new events. Run process_calendar_replies.sh to archive them.
3. ALWAYS ASK BEFORE CREATING - Never create calendar events without explicit user confirmation in the current conversation
4. CHECK IF ALREADY PROCESSED - Before processing any email, check processed_emails in index.json
5. READ CONFIG FIRST - Load and apply ignore_patterns and auto_create_patterns before presenting events
6. READ MEMORY.MD - Check for user preferences stored from previous sessions
7. INCLUDE ALL CONFIGURED ATTENDEES - When creating/updating/deleting events, always include attendees from config with --attendees flag (and --send-updates all if supported)
8. CHECK TRACKED EVENTS FIRST - Use lookup_event.sh --email-id to find existing events before calendar search (faster, more reliable)
9. TRACK ALL CREATED EVENTS - The create_event.sh script automatically tracks events; use tracked IDs for updates/deletions
10. SHOW DAY-OF-WEEK - Always include the day of week when presenting events for user verification

⛔ FORBIDDEN: DO NOT USE gog COMMANDS DIRECTLY ⛔

WRONG: gog calendar create ... or gog gmail ... RIGHT: "$SCRIPTS_DIR/create_event.sh" ... or "$SCRIPTS_DIR/email_read.sh" ...

Direct CLI calls bypass event tracking, break duplicate detection, and cause duplicate events. ALL operations MUST go through the wrapper scripts in scripts/.

Email to Calendar Skill

Extract calendar events and action items from emails, present them for review, and create/update calendar events with duplicate detection and undo support.

First-time setup: See SETUP.md for configuration options and smart onboarding.