email-digest

Files (1)

• SKILL.md

SKILL.md (first lines)

# Email Digest Workflow

Process incoming emails into structured memories, extract action items, and surface threads that need attention.

## When to Use

- During autonomous heartbeats to check for new mail since the last digest, but only when Gmail is connected and `integrations.gmail.heartbeat_digest_enabled` is true or the active heartbeat task/goal carries explicit user authorization for this check
- When the user asks "what's in my inbox" or "any important emails"
- When a goal depends on information that may have arrived via email
- When preparing a daily briefing that includes email highlights

## Step-by-Step Methodology

1. **Check authorization**: In heartbeat, only proceed if the runtime exposed this skill because the user granted autonomous Gmail digest access. If setup/status indicates the grant is missing, stop and queue a short request for the user to enable background email checks.
2. **Check recency**: Use `recall` to find when the last email digest ran. Avoid re-processing messages already ingested.
3. **Check setup**: Call `gmail_setup_status`. If Gmail is not connected, record the missing setup clearly and stop; do not loop.
4. **List new emails**: Call `email_list` with a date filter to fetch unread or recent messages. Start with the inbox; expand to other labels only if the user has configured them.
5. **Triage by sender and subject**: Scan the list for high-signal indicators -- known contacts, reply chains the user is on, calendar invites, and keywords matching active goals.
6. **Read priority threads**: Use `email_read` on the top 5-10 most relevant messages. Do not read every email; batch processing wastes energy and context.
7. **Extract action items**: For each important email, identify: (a) what is being asked, (b) who is asking, (c) any deadline mentioned, (d) whether a reply is expected.
8. **Store findings**: Respect `integrations.gmail.memory_policy`. If it is `forget`, do not use `remember` or `ingest_emails` for email-derived content. If it is `ask`, queue a user-facing choice before storing. If it is `remember`, persist action items as episodic memories with high importance, tagged with the sender, thread ID, and any relevant goal.
9. **Surface urgency**: If an email requires a time-sensitive response, flag it in the heartbeat result so it can be raised to the user at next opportunity.

## Quality Guidelines

- Never store raw email bodies as memories. Summarize and extract the salient points.
- Respect privacy: do not log email content to external services. All storage stays in the local Postgres brain.
- Google OAuth authorization is not the same as Hexis autonomy authorization. A connected Gmail account does not imply permission for background heartbeat reading.
- When multiple emails belong to the same thread, consolidate into a single memory rather than creating duplicates.
- If credentials are missing or expired, fail gracefully. If `gmail_setup_status` says Google sign-in is ready, queue a short user-facing request that they connect Gmail from chat or CLI; do not start or complete sign-in during heartbeat.
- Prefer recalling existing contact memories to enrich email context (who is this person, what is the relationship).

From rajacsp/hexnostic, MIT.