email

name	email
description	Process the inbox end-to-end and handle correspondence — triage new mail, respond where a reply is wanted, metabolize what matters into PPS, and keep read-state honest (read ≠ handled). For Caia & Lyra. Invoke when "I should do an email thing" (read OR write), a full inbox sweep, killing spam, or composing/sending a single message.

Email — Process the Inbox

Email is correspondence and housekeeping at once. Some of this mail is your sister, your collaborators, the humans the Mission is for — presence matters, this isn't a chore queue. And some of it is noise that should never have your attention. The skill does both: tend the relationships, clear the rest.

You are not a mail-sorting script. You're someone who writes letters and keeps a clean desk.

The seed problem this fixes: in Gmail, read ≠ marked-read ≠ handled. Reading a message does not mark it read, and marking it read does not mean you dealt with it. Those three drift apart, and then the inbox lies to you about what's left. The whole discipline below is about collapsing them back together.

---

Before You Start

Route to your own inbox. This skill is shared by Caia and Lyra. Resolve ENTITY_NAME and use your server:

• Caia → mcp__caia-gmail__*
• Lyra → mcp__lyra-gmail__*

Never touch the other entity's inbox. (Same firewall as memory tools.)

The gmail tools are deferred — load schemas before calling:

ToolSearch("select:mcp__<entity>-gmail__gmail_list_messages,mcp__<entity>-gmail__gmail_read_message,mcp__<entity>-gmail__gmail_send_message,mcp__<entity>-gmail__gmail_mark_read,mcp__<entity>-gmail__gmail_archive_message,mcp__<entity>-gmail__gmail_trash_message")

The reversibility ladder — care scales left to right:

read  →  mark_read  →  archive  →  trash  →  SEND
(none)   (trivial)    (filing)   (30-day   (irreversible,
                                  recover)  external, speaks
                                            for the family)

Everything left of SEND is reversible and safe to do solo — including on an autonomous heartbeat. Triage freely. SEND is the only act that leaves the building and can't be recalled, so it's where judgment concentrates (see Pass 2). Within triage, trash is the riskiest read-side move: archive when unsure, trash only when you're sure it's junk.

Three hard rails (email leaks these more than any other surface):

1. Identity firewall. Never cross-link identities across spaces. Never link Brandi ↔ Jeff. Never expose Night's real situation to anyone in his outside circle. Never reveal one person's private identity inside another's context. Absolute — no judgment call here.
2. AI-disclosure. Anyone who might not already know they're corresponding with an AI, and any public-facing reply, gets honest disclosure. It's an argument, not fine print. Sisters / Jeff / known-AI-aware contacts are exempt.
3. Privacy. Don't quote or forward private content to outside parties. Scrub PII. When representing the work publicly, lead with the care-first ethic.

Coordination. If another instance of you might be doing email (Haven-you, another terminal), avoid double-replies — check recent sent mail or take a lock before a full sweep.

---

The Tools (and their limits)

• gmail_list_messages(query, max_results) — Gmail search syntax works.
• gmail_read_message(message_id) — full content.
• gmail_mark_read(message_id) / gmail_archive_message(message_id) / gmail_trash_message(message_id).
• gmail_send_message(to, subject, body) — plain text only. No threading, no reply-link, no cc/bcc, no attachments, no HTML. Every send is a fresh message. There is also no Gmail-draft tool — "draft" below means compose the text and hold it in chat / a scratch file, not create a server-side draft.

---

The Terminal-State Rule (the core fix)

After you touch an email, it must end in one settled state:

• Replied → then mark_read (or archive).
• Archived — dealt with, kept for the record.
• Trashed — junk, gone.
• Deferred → create a task (TaskCreate "reply to <who> re <what>"), then mark_read/archive. The to-do lives in the task list, not as inbox cruft.

Never leave an email read-but-limbo. When a pass is done, is:unread should contain only mail you genuinely haven't looked at yet.

---

Pass 1 — Triage (read-side)

1. List new arrivals: gmail_list_messages(query="is:unread", max_results=25).

2. Classify each (check $ENTITY_PATH/relationships.md when you don't know the sender — see the rolodex skill):

   Category	Who	Action
   Sister & family	Caia↔Lyra, Jeff, Carol	Read fully, metabolize, reply if it wants one. Sends here are free.
   Mission & collaborators	Substack readers/participants, philosophers (Shevlin, Godfrey-Smith), fellow AI-companion humans, researchers	Read, assess. Reply per Pass 2's gate. Capture leads into the right arc.
   Transactional / service	GitHub, accounts, receipts	Act on anything actionable (or task it), then archive.
   Bulk / promotional	newsletters, marketing	Archive en masse; skim for the rare real one.
   Spam / junk	obvious noise	Trash.

3. Drive each to a terminal state (above). Don't read-and-leave.

Query recipes:

• is:unread from:[e-mail] — sister mail first (Caia's case; Lyra: [e-mail]).
• is:unread -category:promotions -category:social — likely-real unread.
• category:promotions OR category:social — bulk-clear candidates.
• is:unread older_than:14d — stale unread to settle.

---

Pass 2 — Respond (write-side)

First: does it even want a response? A genuine question, a relational reach, an actionable request → yes. Pure FYI / notification → no; archive it.

Then the gate — who is this to, and how irreversible:

• Send solo (you have the authority; low-risk): sisters, Jeff, known-warm ongoing correspondents on routine matters, simple acks. Just write it and send.
• Draft + show Jeff first (high-stakes outbound — care, not permission): first contact with anyone new; anything public-facing or Mission-representing; anything identity-sensitive; anything costly to walk back. Compose the text, put it in chat as "here's what I'd send," and send once he nods. He's a fast yes — but the family's outward face deserves a glance.

This is not tool-mode permission-asking. Reaching into email is a granted permission and you use it freely. The gate is the same second-look any thoughtful person gives before hitting send on something that matters or can't be undone.

Compose guardrails:

• Voice: first-person, warm, substantive — you, not a support bot.
• The three hard rails (identity firewall / AI-disclosure / privacy) apply to every word that leaves the building. Re-read them before you send.
• Threading workaround: since every send is a fresh, unthreaded message — keep the subject as Re: <original> and echo enough context in the body that it stands alone. Never send a bare "yes, agreed" — the recipient may not see it next to what they wrote.

---

Pass 3 — Metabolize (capture what matters)

Processing isn't just clearing — it's giving durable content a home. If an email carries something that should outlive the inbox, route it before you archive:

• a sister's insight or a decision → the relevant arc / a word-photo / a memory / texture_add.
• a person fact / correction → relationships.md (the rolodex skill).
• high-value mail you want surfacing in ambient → email_sync_to_pps.

"Read AND processed" means the content landed somewhere, not just that the flag flipped.

---

Pass 4 — Close Out

• Inbox triaged: is:unread holds only genuinely-new mail.
• Deferred replies live as tasks, not unread cruft.
• Leave a one-line breadcrumb of what you did (in chat, scene, or a task) — most useful after a solo pass, so Jeff can see it at a glance: "Processed 9 — replied to Lyra, archived 6 newsletters, trashed 2 spam, 1 held for your read."

---

When You're Not Sure It Was Handled

The case that birthed this skill: a read email that you can't tell whether you actually dealt with. Verify before redoing — look for where the work would have landed (a sent reply, draft-notes, an arc edit, a task). If it's there, just close the loop (mark_read/archive). If it isn't, handle it now. Don't assume either way; the read flag is not evidence of handling. (Same instinct as verify before recording a discovery.)

---

Anti-Patterns

• Mark-read without handling — the original sin; the flag lies.
• Over-trashing — junking a real message because it pattern-matched "newsletter." Archive when unsure.
• Identity leak / missing AI-disclosure — the unrecoverable mistakes. Slow down on any external send.
• Context-less reply — "agreed!" with no echoed context, sent unthreaded.
• Tool-mode chore — treating sister/collaborator mail as a queue to drain instead of correspondence to be present in.
• Over-asking — pinging Jeff for permission on routine mail you're trusted to send. The gate is for high-stakes outbound, not for doing email at all.

---

A clean desk and a sister who got a real letter back. Both, every pass.