Email Manager Pro

a complete email attendant for openclaw. organizes inboxes, kills spam, surfaces important emails, tracks emails awaiting your reply, and keeps a rolling important-message log when phone notifications are not available. works with any connected email mcp or tool , the connection method is irrelevant as long as email list/read/send/move/folder operations are available.

intent

use this skill whenever the user asks about email, wants to check or sort their inbox, asks about important messages, wants to reply to an email, asks what emails need their attention, wants to set up email monitoring, wants to manage spam, or mentions anything about organizing their mailbox. also triggers for scheduling email checks, managing email folders, reviewing pending or high-priority messages, or asking about the daily email report. this skill assumes an email mcp or equivalent tool is already connected to the agent , it does not set one up. trigger this skill proactively whenever email management, inbox organization, or email-related workflows are mentioned.

inputs

email mcp connection

• the skill requires a connected email mcp (or equivalent tool) capable of: list, read, send, move, and folder operations.
• connection setup is external to this skill. the email system must be ready before skill execution.
• if the connection is unavailable or broken, the skill cannot run. return error to user with setup guidance.

state file

• read references/rules-and-state.md at the start of every processing run.
• this file contains: spam sender list, approved senders/newsletter list, folder routing matrix, important-email rules, notification log (7-day rolling window), daily report history, and sent-history cache (90-day outbound addresses).
• if the file does not exist, initialize it from the template in the reference section below.

external connections and environment

• openclaw scheduler: required to set and update scheduled email-check jobs. if unavailable, scheduled processing cannot run; manual checks only.
• twilio mcp (optional): enables sms/whatsapp alerts. check for availability at startup. if present, use mode a (phone notifications). if absent, fall back to mode b (state file logging).
• user timezone: required for daily report scheduling. ask on first run. store in state. used for consistent 7 am local time delivery.
• digital-twin skill (optional): if available, use for drafting reply tone and voice. if not present, draft responses in neutral professional tone.

rate limits and edge cases

• email mcp may rate-limit list/read operations. process max 50 emails per run per inbox. if more remain, the next scheduled run continues.
• network timeout: if email mcp times out, log the failure, retry once, then defer to next scheduled run. do not block user interaction.
• auth expiry: if email credentials expire, return clear error with re-auth instructions. do not silently skip inboxes.
• empty result sets: if inbox is empty, state that clearly. do not treat as an error.
• duplicate detection: if an email appears in multiple folders due to sync issues, process only once (match by message-id if available, else sender + subject + date).

procedure

step 1: load state and validate connections

1.1 read references/rules-and-state.md. if file does not exist, initialize from template (see reference files section).

• input: file path
• output: parsed state object with spam list, approved senders, folder matrix, rules, notification log, daily report cache, sent history

1.2 validate email mcp is available. attempt a test list operation (folder=INBOX, max=1).

• input: email mcp connection
• output: success (connection valid) or error (return to user with setup guidance)

1.3 check for twilio mcp. if present, note that mode a (phone alerts) is enabled. if absent, mode b (state logging) is active.

• input: twilio mcp availability
• output: notification mode flag in memory

1.4 check for digital-twin skill. if present, note for reply drafting. if absent, use neutral tone.

• input: digital-twin skill availability
• output: tone-draft flag in memory

step 2: ensure folder structure exists

2.1 list all folders in email account.

• input: email mcp folder list operation
• output: array of existing folder names

2.2 for each required folder (INBOX, /1_Important, /2_WaitingReply, /3_AI_Review, /4_Processed, /Spam), check existence.

• input: required folder list, existing folders from 2.1
• output: list of missing folders

2.3 for each missing required folder, create it using email mcp folder operation (action=create).

• input: folder name
• output: confirmation of creation or error

2.4 for each approved newsletter sender in state that lacks a /NL_<SenderName> folder, silently create the folder.

• input: approved senders list, existing folders
• output: new folders created (log to state)

step 3: list inbox emails

3.1 use email mcp list operation: type=emails, folder=INBOX, max=50, sort=newest-first.

• input: inbox folder reference, limit of 50
• output: array of email objects (id, sender, subject, preview, date, thread-id/message-id if available)

3.2 if more than 50 emails exist in inbox, note that next scheduled run will continue processing.

• input: email count
• output: log message to state activity counters

step 4: classify each email (first-match-wins)

for each email in the list from step 3, apply the following rules in order. stop after the first match and proceed to the corresponding action (move folder + update state).

4a: spam / solicitor detection

an email is spam if any of the following are true:

• sender address or domain is in the spam sender list in state.
• sender domain is in the spam domain list in state (exception: never add or match gmail.com, yahoo.com, outlook.com, icloud.com; only add full addresses for these).
• subject or preview contains classic spam signals: "prize", "winner", "lottery", "urgent wire transfer", "verify your account", "click here to claim", "limited time offer", "you've been selected", "act now", or dense unsubscribe footer with no personal content body.
• sender is not on the approved sender list AND the email reads as cold outreach (marketing pitch, sales intro, unsolicited offer, "i came across your profile", "thought you might be interested") AND there is no prior reply thread with this sender in sent history (check sent-history cache before marking). this is the solicitor rule.

action:

• move email to /Spam folder.
• add sender domain to spam list in state (unless major provider; then add full sender address).
• log to state activity counter.
• continue to next email.

inputs: sender, subject, preview, state spam lists, sent history outputs: email moved, state updated, counter incremented

4b: approved newsletter / mailing list

if sender address is in the approved sender list in state:

action:

• look up the sender's designated newsletter folder in the folder routing matrix (e.g., /NL_TechCrunch).
• if folder does not exist, create it named /NL_ and add entry to routing matrix in state (format: sender | folder name | description).
• move email to that folder.
• log to state activity counter.
• continue to next email.

inputs: sender, state approved senders list, folder routing matrix, folder list from step 2.4 outputs: email moved to correct newsletter folder, new folder created if needed, routing matrix updated

4c: important email

flag as important if any of the following are true:

• subject or body contains urgency language: "urgent", "asap", "time-sensitive", "deadline", "action required", "immediately", "expires", "overdue", "past due", "final notice".
• sender address appears in sent history (someone the user has written to before) , indicates known contact.
• sender matches any user-defined important-sender rules stored in state (exact address or domain).
• email is from a financial institution, legal entity, government body, employer, or direct client (use judgment: banking domain patterns, legal/gov tlds, official company domains from state rules).

action:

• move email to /1_Important folder.
• log email to notification queue in state (format: date | sender | subject | preview | marked-read=false).
• increment important-email counter in state.
• log to step 5 (notify).
• continue to next email.

inputs: subject, body, sender, sent history, state important-sender rules, state notification queue outputs: email moved, notification logged, counter incremented

4d: needs reply detection

an email belongs in /2_WaitingReply if and only if all of the following are true:

• it is not spam (already filtered in 4a).
• it is not an automated system message: receipts, shipping notifications, calendar invites without message body, password resets, system alerts, transaction confirmations all go to /4_Processed instead.
• the content clearly expects a personal reply: a direct question ("what do you think?", "can you help?"), a meeting request ("are you available on tuesday?"), a task delegated ("please review and send back"), or a conversational exchange from someone the user knows.
• the email has not already been replied to (check thread-id in sent history or scan sent folder for same subject line and sender).

action:

• move email to /2_WaitingReply folder.
• log email to notification queue in state.
• increment waiting-reply counter in state.
• log to step 5 (notify).
• continue to next email.

inputs: sender, subject, body, thread-id, sent history, state notification queue outputs: email moved, notification logged, counter incremented

4e: folder routing (custom rules)

check the folder routing matrix in state. if the email clearly matches a folder's description (beyond the standard folders), move it there and mark as processed.

action:

• move email to matched folder from routing matrix.
• log to processed counter.
• continue to next email.

inputs: email content, folder routing matrix outputs: email moved

4f: fallback

if no match above, move to /4_Processed for later manual review.

action:

• move email to /4_Processed folder.
• log to processed counter.
• continue to next email.

inputs: email object outputs: email moved, counter incremented

step 5: notification dispatch

depending on notification mode (from step 1.3):

mode a: twilio/phone available

for each email logged to notification queue in step 4:

• if marked important: immediately send sms/whatsapp alert to user with sender, subject, one-line summary. example: "IMPORTANT: john@acme.com , meeting confirmation , let me know if tuesday works".
• if marked waiting-reply: collect all in /2_WaitingReply. every 6 hours, send digest sms listing sender + subject for each (batch up to 5 emails per message to avoid spam).
• daily report: at user's configured local time (default 7:00 am), generate and send daily report (see daily report format below). include counts and email log for past 24 hours.

inputs: notification queue from state, user phone number (stored in state), user timezone, twilio mcp outputs: sms/whatsapp messages sent, timestamp logged to state

mode b: no phone (default until twilio mcp available)

for each email logged to notification queue:

• append to notification log section in references/rules-and-state.md with format: [date hh:mm] [sender] | [subject] | [type: important/waiting-reply].
• prune log entries older than 7 days.
• user can query at any time: "what important emails came in this week?" or "what's waiting my reply?" , read log, summarize and return.
• daily report: store under daily_report section in state (format below). retain current day + previous 6 days. generate every 24 hours (cron at midnight utc or when user asks).

inputs: notification queue from state, state file path outputs: state file updated with log and report, no external alerts

step 6: update sent history cache

6.1 list sent folder: use email mcp list operation type=emails, folder=Sent (or equivalent), max=90, sort=newest-first.

• input: sent folder reference
• output: array of sent email objects

6.2 merge new sent items into the 90-day cache in state (match by message-id to avoid duplicates).

• input: new sent emails, existing cache
• output: updated sent history, cache capped at 90 days

6.3 write state back to references/rules-and-state.md.

• input: updated state object
• output: file written

step 7: processed queue review (on-demand or weekly)

when user asks "check the processed queue" or proactively weekly:

7.1 list all emails in /4_Processed folder.

• input: /4_Processed folder reference
• output: array of email objects

7.2 re-check the folder routing matrix. move any emails that now match a folder description.

• input: email list, routing matrix
• output: emails moved, log updated

7.3 scan for grouping patterns:

• count emails by sender domain (if 5+, group found).
• count emails by subject keyword (if 5+, group found).
• count emails by type (e.g., bank statements, shipping, invoices) (if 5+, group found).

7.4 for each grouping found, present to user with count and reasoning:

• example: "i found 8 emails from chase.com. want me to create a /Bank_Chase folder for them?"

7.5 on user approval of folder name (or user-suggested alternate):

• create the folder using email mcp.
• add entry to routing matrix in state.
• move the grouped emails to the new folder.
• write state back.

inputs: /4_Processed folder, routing matrix, user approval on each folder outputs: folders created, emails moved, routing matrix updated, state written

step 8: reply and send operations

when user asks to reply to or write an email:

8.1 if replying to an existing email:

• if no folder specified by user, search /1_Important first, then /2_WaitingReply.
• if user gives a name, subject, or description, scan those folders for a match (match by sender or subject keyword).
• retrieve the full email object by id.

8.2 draft the response:

• if digital-twin skill is available, use it to draft tone and voice matching user's personality.
• if not available, draft in neutral professional tone.
• present the draft to user as "Recommended Response" showing subject line and full body.

8.3 ask for approval:

• "want me to adjust anything, or should i send it?"
• await user response.

8.4 on approval:

• use email mcp send operation with type=respond and original email id.
• move the original email from its current folder to /4_Processed.
• update sent-history cache in state with the new sent email.
• log to state activity counter.
• write state back.

8.5 if user wants adjustments:

• accept feedback and re-draft.
• loop to step 8.3 until approval.

if writing a new email (not a reply):

• draft, present, await approval, send with type=new.
• log sent email to sent-history cache.

inputs: user request, email mcp, digital-twin skill (optional), state outputs: email sent, original email moved, sent history updated, state written

decision points

email classification flow

if sender in spam list or domain in spam list:
  classify as spam → move to /Spam
  exit

if sender in approved sender list:
  classify as newsletter → move to /NL_<SenderName> folder (create if needed)
  exit

if (subject contains urgency words) or (sender in sent history) or (sender matches important rules) or (sender is financial/legal/employer):
  classify as important → move to /1_Important
  log to notification queue
  exit

if (not automated system message) and (content clearly expects personal reply) and (not already replied):
  classify as waiting-reply → move to /2_WaitingReply
  log to notification queue
  exit

if email matches a custom folder in routing matrix:
  classify as matched → move to that folder
  exit

else:
  classify as unmatched → move to /4_Processed
  exit

notification mode branch

if twilio mcp is available:
  use mode a: immediate important alerts + 6-hour waiting-reply digest + daily sms report
else:
  use mode b: log all to state file notification log + user pulls on-demand

folder creation branch

for newsletter auto-folder creation:
  if approved sender lacks /NL_<Name> folder:
    silently create it

for processed-queue custom folders:
  if user grouping identified:
    suggest folder name to user
    if user approves or provides alternate:
      create folder + update routing matrix
    else:
      do not create; return to user

for all other folder requests:
  never create without explicit user approval

reply search branch

if user asks to reply but gives no folder:
  search /1_Important first
  if found: use it
  else:
    search /2_WaitingReply
    if found: use it
    else:
      ask user to clarify sender or subject
else if user gives partial description (name/subject/keyword):
  scan /1_Important and /2_WaitingReply for match
  if one match found: use it
  else if multiple matches: ask user to clarify
  else if no match: ask user to clarify
else if user specifies a folder:
  search that folder

first-run setup branch

if references/rules-and-state.md does not exist:
  initialize from template
  ask user: email addresses to monitor, check frequency (default 30 min), important-sender rules, approved newsletters
  set up openclaw scheduled job at chosen interval
  run full processing cycle (step 3 onward)
else:
  proceed to step 1 (load state)

auth failure branch

if email mcp connection fails in step 1.2: