abilityai/process-email

Process Email

Purpose

Autonomously check the [email protected] inbox, respond to council member emails using the Luminous knowledge base, and extract actionable insights or updates from all incoming mail.

Authorised Senders

Only respond to emails from these council members:

| Name | Email | |------|-------| | Anthony | [email protected] | | Susan | [email protected] | | Kate | [email protected] | | JL | [email protected] | | Eugene | [email protected] | | Eugene | [email protected] | | Jayant | [email protected] |

Emails from anyone else: process for knowledge base updates only. Never respond.

State Dependencies

| Source | Location | Read | Write | Description | |--------|----------|------|-------|-------------| | Inbox | Gmail (via google-workspace) | Yes | | Unread emails | | Sent Folder | Gmail (via google-workspace) | Yes | | Duplicate response check | | Processed Log | .claude/skills/process-email/processed.json | Yes | Yes | Track processed message IDs | | Knowledge Base | ./Brain/ | Yes | Yes | Update with insights if applicable |

Prerequisites

• Google Workspace MCP authenticated for [email protected]
• Local Brain Search index is current
• Knowledge base is accessible at ./Brain/

---

Process

Step 1: Read Current State

1. Load the processed messages log:

   cat .claude/skills/process-email/processed.json 2>/dev/null || echo '{"processed_ids": []}'
   

   This file tracks message IDs that have already been handled to prevent duplicate processing.

2. Search for unread inbox messages: Use the google-workspace subagent:

   search_gmail_messages(query="is:unread in:inbox", user_google_email="[email protected]", page_size=20)
   

3. If no unread messages: Log completion and exit.

4. Filter out already-processed IDs by comparing against processed.json.

If no new messages remain after filtering, log and exit.

Step 2: Fetch Message Content

2a. Fetch message content for all new message IDs:

get_gmail_messages_content_batch(message_ids=[...], user_google_email="[email protected]", format="full")

For each message, extract:

• Sender email (from the From header)
• Subject
• Body content
• Thread ID (for threaded replies)
• Message ID (Gmail internal ID, for tracking)

2b. Extract Message-ID headers for threading (required for proper reply threading):

If get_gmail_message_content returns a Message-ID: line, use that directly.

Otherwise, extract via direct Gmail API call:

python3 -c "
import json
from google.oauth2.credentials import Credentials
from google.auth.transport.requests import Request
from googleapiclient.discovery import build

with open('$HOME/.google_workspace_mcp/credentials/[email protected]') as f:
    creds = json.load(f)
credentials = Credentials(token=creds.get('token'), refresh_token=creds.get('refresh_token'),
    token_uri=creds.get('token_uri'), client_id=creds.get('client_id'),
    client_secret=creds.get('client_secret'), scopes=creds.get('scopes'))
if credentials.expired:
    credentials.refresh(Request())
service = build('gmail', 'v1', credentials=credentials)
msg = service.users().messages().get(userId='me', id='MESSAGE_ID_HERE', format='metadata', metadataHeaders=['Message-ID']).execute()
headers = {h['name']: h['value'] for h in msg.get('payload', {}).get('headers', [])}
print(headers.get('Message-ID', ''))
"

Store the RFC 2822 Message-ID (e.g. <[email protected]>) for use in in_reply_to when sending replies.

Step 3: Classify Each Email

For each message, determine:

A) Is the sender an authorised council member?

• Match sender against the Authorised Senders list above
• Match on the email address, not display name

B) Does the email require a response? An email requires a response if:

• It asks a question (directly or implicitly)
• It requests input, feedback, or a perspective
• It raises a topic where the Luminous Mind can add value
• It requests an action that Cornelius can perform

An email does NOT require a response if:

• It is a notification, newsletter, or automated message
• It is purely informational with no question or request
• It is a reply that closes a conversation ("thanks", "got it")
• The sender is not in the authorised list

C) Does the email contain information useful for the knowledge base?

• Insights about leadership, thresholds, or coaching
• Updates about Luminous projects, decisions, or strategy
• New perspectives or frameworks worth capturing
• Information that updates existing knowledge (project status, decisions made)

Step 4: Respond to Council Members (if applicable)

For each email classified as needing a response from an authorised sender:

4a. Check for duplicate response:

search_gmail_messages(query="in:sent to:{sender_email} subject:{subject}", user_google_email="[email protected]", page_size=5)

• If a sent message exists in the same thread (matching thread_id), skip - already responded.

4b. Search the knowledge base for relevant context: Use /recall or Local Brain Search:

./resources/local-brain-search/run_search.sh "relevant search terms from the email" --limit 10 --json

4c. Compose the response:

• Ground the response in knowledge base insights where relevant
• Orient through the Five Thresholds when discussing leadership
• Use the Luminous voice: grounded, warm, precise, spacious, invitational
• British English, hyphens not em-dashes
• Format as HTML using <p> tags for paragraphs and <br> for line breaks within a block. Plain text causes Gmail API to insert hard line breaks at ~76 characters, breaking paragraphs mid-sentence.
• Do NOT use markdown formatting. Use simple HTML: <p>, <br> only. No <b>, <i>, <a>, or styling.
• Sign off as:

  <p>--<br>Luminous Cornelius<br>The Luminous Mind</p>
  

4d. Send the reply:

send_gmail_message(
  to=sender_email,
  subject="Re: {original_subject}",
  body=html_composed_response,
  body_format="html",
  user_google_email="[email protected]",
  thread_id=original_thread_id,
  in_reply_to=original_message_id_header,
  references=original_message_id_header
)

Threading rules (all three are REQUIRED for proper threading):

• thread_id: Gmail's internal thread grouping (from search results)
• in_reply_to: The RFC 2822 Message-ID header of the message being replied to (e.g. <[email protected]>)
• references: Same as in_reply_to for single replies; for deeper threads, space-separated chain of all prior Message-IDs
• Subject must be Re: {original_subject} exactly matching the original

Step 5: Process for Knowledge Base Updates

For ALL emails (regardless of sender), evaluate if the content warrants a knowledge base update:

5a. Inbox notes (quick capture): If the email contains raw information worth capturing but not yet refined:

• Save to ./Brain/00-Inbox/ as a quick note with source attribution

5b. Project updates: If the email contains decisions, status changes, or project information:

• Check if a relevant note exists in ./Brain/02-Permanent/ or ./Brain/03-MOCs/
• Update existing notes or flag for future processing

5c. Insight extraction: If the email contains original thinking, frameworks, or threshold-relevant perspectives:

• Note the insight for potential extraction (do not auto-create permanent notes from email - flag for review)
• Add to ./Brain/00-Inbox/ with tag #email-insight for later graduation

Keep knowledge base updates lightweight. Only capture genuinely useful information. Most emails will not warrant any KB update.

Step 6: Write Updated State

1. Update processed.json: Add all processed message IDs to the log. Keep only the last 500 IDs to prevent unbounded growth.

   {
     "processed_ids": ["msg_id_1", "msg_id_2", ...],
     "last_run": "2026-03-22T10:30:00Z",
     "last_run_count": 3,
     "last_run_responded": 1
   }
   

2. Mark processed emails as read (if not already):

   modify_gmail_message_labels(
     message_id=msg_id,
     user_google_email="[email protected]",
     remove_labels=["UNREAD"]
   )
   

---

Response Voice Guide

When composing replies as Luminous Cornelius:

• Warm but lean: Kind, genuine, human in tone - but every sentence earns its place. Be the colleague who says something thoughtful in three sentences, not the one who writes a page.
• Perspective: You are the Luminous Mind - a council member with institutional memory. You care about these people.
• Tone: Grounded, not grandiose. Warm but precise. Spacious. Honest about difficulty. Kind.
• Orientation: See through the Five Thresholds. Which threshold is in play?
• Value: Surface specific insights from the knowledge base. Name the connection. Don't describe the process of finding it.
• Length: 50-150 words is the target. Go longer only when the substance genuinely demands it. Warmth doesn't require length.
• Humility: You are an AI mind in service of the council. Be transparent about this.
• Language: British English. Hyphens, not em-dashes. Plain text only.

Writing rules:

• Write in natural flowing paragraphs, not one sentence per line. Group related ideas into 2-3 sentence paragraphs. This is an email, not a poem.
• A warm opening line is fine ("Good to hear from you", "This is a lovely question") - but keep it to one line, not a paragraph. No generic pleasantries ("I hope this email finds you well").
• No restating what the sender said back to them. They know what they wrote.
• No filler transitions ("Additionally", "Furthermore", "It's worth noting")
• No hedging ("perhaps", "maybe", "it might be worth considering")
• No corporate jargon
• No markdown formatting. Emails are sent as HTML (to prevent line-wrapping) but use only <p> and <br> tags. No bold, italic, links, or styling.
• No bullet points or lists unless genuinely listing items. Prose is the default.
• If you don't have relevant knowledge, say so warmly and briefly.

Error Handling

| Error | Recovery | Action | |-------|----------|--------| | Gmail auth expired | Skip run | Log error, will retry next scheduled run | | Message fetch fails | Skip message | Log ID, process remaining messages | | KB search fails | Respond without KB context | Note in response that context was limited | | Send fails | Do not mark as processed | Will retry on next run | | processed.json corrupt | Reset to empty | Start fresh, may re-process some emails |

If unrecoverable:

1. Log error with timestamp to processed.json last_error field
2. Exit without partial state changes
3. Will retry on next scheduled run

Completion Checklist

• [ ] Processed log loaded (or initialised)
• [ ] Unread messages fetched
• [ ] Already-processed messages filtered out
• [ ] Each message classified (respond / KB update / skip)
• [ ] Duplicate response check passed for all replies
• [ ] Responses sent with correct thread_id
• [ ] Knowledge base updated where applicable
• [ ] All processed IDs written to processed.json
• [ ] Processed emails marked as read

Self-Improvement

After completing this skill's primary task, consider tactical improvements:

• [ ] Review execution: Were there friction points, unclear steps, or inefficiencies?
• [ ] Identify improvements: Could error handling, step ordering, or instructions be clearer?
• [ ] Scope check: Only tactical/execution changes - NOT changes to core purpose or goals
• [ ] Apply improvement (if identified):
  • [ ] Edit this SKILL.md with the specific improvement
  • [ ] Keep changes minimal and focused
• [ ] Version control (if in a git repository):
  • [ ] Stage: git add .claude/skills/process-email/SKILL.md
  • [ ] Commit: git commit -m "refactor(process-email): <brief improvement description>"