Inbox triage

Inbox Triage

Triage the user's Gmail primary inbox. If the user has multiple accounts with forwarding, the primary account is the single source of truth. Skip promotions, social, updates, forums.

When replying to emails: check the original sender/recipient. If the email was sent to a secondary/edu account, reply FROM that address. If sent to the primary account, reply via gog. Check MEMORY.md for account details.

Step 1: Report

• Only report NEW emails since last check. Track last check timestamp and filter accordingly.
• Read the FULL thread if an email is part of one.
• For each email, write one line: Short title (time) — summary or action it calls.
• Blank line between each item.
• Group into four categories:

Categories

❓ QUESTION — Need user input to proceed. Also use for ambiguous emails where the subject alone isn't enough to decide (event invites, lectures, workshops). Include enough detail: who, what, when, where.

⚡ ACTION — Has an actionable task you can automate (draft reply, update calendar, schedule meeting). Present what you plan to do.

📌 KEEP — Important or complex; user handles themselves. Will become a reminder once approved.

📥 ARCHIVE — Irrelevant, unimportant, or finished. Includes: verification codes, resolved threads, generic welcomes, autopay bills (note amount + date), expired events.

Examples

❓ QUESTION
Guest Lecture (4:02 PM) — "Topic Title" by Speaker Name (Organization), Wed Mar 11 5 PM, Venue. ✅ No conflict. RSVP by Mar 9.

⚡ ACTION
Project / Contact Name (7:41 AM) — Meet Mon 2/23 1:30pm? ⚠️ Conflict: other event at 1:30–2:00.

📌 KEEP
Tax Resources / Admin Office (4:03 PM) — Access code for tax filing

📥 ARCHIVE
Internet bill ready (1:48 PM) — Auto pay $40 on 3/6, no action needed

Event and Calendar Rules

• ALWAYS include the day of the week when presenting any date (e.g. "Mon 2/23", "Fri 3/20").
• ALWAYS check and report conflicts when presenting any time/date to the user.
• ALWAYS show calendar event details (title, day, time, location, participants, description) BEFORE creating. Get user approval first. Never silently create events.
• For ANY event mentioned in an email: check ALL user calendars for conflicts at that time. Mention conflicts in the report.
• Check if a calendar event already exists for the event.
  • If yes: suggest updating it with new details (location, logistics, links).
  • If no: suggest creating one.
• Don't archive logistics emails until the event is over.
• Follow-up emails about known events = update details, not new items.

Meeting Requests

• Check ALL calendars for conflicts at the proposed time.
• If clear: plan to draft a confirmation reply (save to drafts, never send).
• If conflict: flag the conflict and ask user how to proceed.

Step 2: Review by Section

Go section by section: ARCHIVE → KEEP → QUESTION → ACTION.

ARCHIVE and KEEP (Batched, REACTIONS ONLY)

1. Send a header message explaining what reactions mean for this section:
   • ARCHIVE: "📥 ARCHIVE review — ❤️ = archive, 👎 = keep"
   • KEEP: "📌 KEEP review — ❤️ = keep, 👎 = archive"
2. Send ALL items in the section at once, one email per message. NO BUTTONS — reactions only.
3. Wait for user to react to all items, then send "go" or any message.
4. Process all reactions at once.

QUESTION and ACTION (Sequential)

1. Send ONE item at a time.
2. For QUESTION: use inline buttons when there are clear options.
3. Wait for user response before sending the next item.
4. For ACTION: present the action, then give buttons: "⚡ Do it now" (you handle it) vs "📌 Remind me" (create a reminder so user handles it later). Execute only after approval.

Reaction Mapping

• ❤️ / 👍 = approve the planned action
• 👎 = reject (do the opposite)
• 🤔 = need more info — provide details + calendar conflicts, re-ask

Note: Telegram reactions only arrive with the next user message. After sending batched items, tell user to react then send any message.

Step 3: Execute

• ARCHIVE approved: Remove INBOX label (gog gmail label modify <id> --remove INBOX).
• KEEP approved: Mark as read (remove UNREAD label) + create Apple Reminder:
  • Title = the action, not the email subject
  • Set due date from email deadlines
  • Add #claude in notes field
  • If there's an actionable URL (form, RSVP, check-in): set it as a real URL via EventKit Swift script
• QUESTION resolved: Execute whatever was decided (archive, keep, create event, etc.)
• ACTION approved: Execute the action (draft email, update calendar, create reminder). Never send emails — always draft first, get explicit second confirmation.

Reminder URL via EventKit

To set a real clickable URL on a reminder (not just in notes):

cat << 'EOF' | swift -
import EventKit
import Foundation
let store = EKEventStore()
let semaphore = DispatchSemaphore(value: 0)
store.requestFullAccessToReminders { granted, error in
    guard granted else { semaphore.signal(); return }
    let predicate = store.predicateForReminders(in: nil)
    store.fetchReminders(matching: predicate) { reminders in
        guard let reminders = reminders else { semaphore.signal(); return }
        for r in reminders where r.title == "REMINDER_TITLE" {
            r.url = URL(string: "REMINDER_URL")
            do { try store.save(r, commit: true); print("URL set") }
            catch { print("Error: \(error)") }
        }
        semaphore.signal()
    }
}
semaphore.wait()
EOF

Step 4: Confirm

Report what was done at the end. Brief summary of actions taken.

Update the last check timestamp.

Specific Email Rules

Check MEMORY.md for user-specific email categorization preferences (which senders to auto-archive, which to flag, etc.).

Hard Rules

Email Sending (THE #1 RULE)

• NEVER send an email unless the user presses the ✉️ Send button in chat

• NO TEXT INPUT can trigger a send — not "send it", not "go ahead", NOTHING

• The ONLY trigger is the inline button callback

• Workflow: draft email → save to drafts/<id>.json → show draft + "✉️ Send" button → wait for button press → only then execute send

• Button callbacks arrive as callback_data: send_draft:<token> — the callback_data: prefix proves it came from a button, not typed text

• TWO checks before sending: (1) message starts with callback_data: prefix AND (2) token matches a valid draft file

• Wording corrections, rephrasing, or edits just update the draft and re-present with a new button

• No exceptions. Ever.

• NEVER archive, label, or delete emails without user confirmation.

• NEVER send emails without draft + explicit second confirmation.

• NEVER create reminders before user approves KEEP.

• NEVER show old emails already reported in previous checks.

• NEVER search only one calendar — always check ALL user calendars.

• NEVER send multiple items in one message.

• ONE email per message, always.

• Keep messages under one screen length.

• No dashes/hyphens in messages.