agentleFS
pholbopholbo/getting-things-adhdone/skills/search-mail/SKILL.md

search-mail

Skill7 starsChanged 49 days agoMITView on GitHub

Searches your email on request via AppleScript against Apple Mail - by subject, sender, or date - and reads back matching messages. Local and read-only, reading the local Mail app rather than going through an OAuth mail connector. Never sends, deletes, moves, or marks anything read. Standalone, on-request only. Trigger: /search-mail, or asking to find/check/look up an email.

The file

We split this skill into the rules it gives an agent

6 rules. About 0 are common, 6 are distinctive, and 0 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈6

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Confirm the search terms: if you haven't given something specific enough to search on directly - a sender name/domain, a subject keyword, …

    line 39
  2. Distinctive:

    Default to whichever mailbox best represents "everything" for the account in question (e.g.

    line 61
  3. Distinctive:

    Read the messages, work out the actual chronology, and summarise each real message once, in order - skip pure auto-replies (out-of-office, …

    line 95
  4. Distinctive:

    Read-only, always. Never send, reply, forward, delete, move, flag, or mark anything read/unread via this skill.

    line 102
  5. Distinctive:

    Never search or summarise mail proactively - only when asked, for the specific thing that was asked about, right now.

    line 104
  6. Distinctive:

    If a search returns nothing, say so plainly rather than broadening the search silently - ask before trying a looser match.

    line 106

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Search Mail

Purpose

Lets you ask "find the email from X about Y" and get an answer, without connecting an OAuth mail connector to a work or personal inbox - useful if that kind of connector isn't available to you, isn't vetted for your organisation's data yet, or you'd simply rather not grant it broad account access for something you only need occasionally. This works entirely through Mail.app, which already has your account(s) configured locally, so it's local file/app access rather than a connector.

On-request only, like link-task - this is not a standing daily scan, and doesn't get called from start-the-day or end-the-day unless you specifically wire that up yourself.

Requires the account in question to be configured in Apple Mail - AppleScript can only see what Mail.app itself has set up. If your email only lives in a browser tab, this doesn't apply until you add it as an account in Mail.app.

Trigger

/search-mail, or asking to find, check, or look up an email/thread.

Process

  1. Confirm the search terms if you haven't given something specific enough to search on directly - a sender name/domain, a subject keyword, or a rough date range. Don't guess at vague requests.
  2. Search by subject or sender first, not body content. Searching content contains across a large mailbox is much slower than subject/ sender since it has to fetch full message bodies to filter - only fall back to a content search if subject/sender genuinely doesn't narrow it down enough, and say so, since it'll be slower.
  3. Query via AppleScript against Mail.app, targeting the right account. First confirm the account name: osascript -e 'tell application "Mail" to get name of every account'.
    • Known quirk (tested against a Gmail account synced into Mail.app): referencing a special mailbox like mailbox "All Mail" of account "<name>" by direct name can fail with error -1728 ("Can't get mailbox"), even though that mailbox genuinely exists and shows up when you list every mailbox of account "<name>" by name. Ordinary mailboxes ("INBOX", "Sent Mail") don't have this problem. If a plain by-name reference throws -1728, iterate every mailbox of account "<name>" and match by name instead, rather than assuming the mailbox doesn't exist.
    • Default to whichever mailbox best represents "everything" for the account in question (e.g. "All Mail" for Gmail-backed accounts, since it covers inbox, archive, and anything filed elsewhere) unless asked to narrow to Sent or a specific mailbox.
    • Example query shape:
      tell application "Mail"
        set acct to account "<account name>"
        set targetBox to missing value
        repeat with m in (every mailbox of acct)
          if name of m is "<mailbox name>" then
            set targetBox to m
            exit repeat
          end if
        end repeat
        set theMessages to (messages of targetBox whose subject contains "<term>")
        -- collect subject, sender, date received of m as string, for each
      end tell
  4. Present matches as a short list first (subject, sender, date) rather than dumping full bodies - if there are several hits, ask which one(s) are actually worth reading in full before pulling content of m for each. If there's an obvious single match, just read it.
  5. Read back the message content plainly - content of m returns the body text directly, no further parsing needed for plain-text mail. Note if a message looks HTML-heavy/hard to read as plain text rather than silently returning a garbled result.
  6. For a full thread (several messages on one subject), present a deduplicated chronological summary, not raw output. Each reply's content includes the full quoted history beneath it, so pulling every message in a thread means the same earlier messages appear repeatedly. Read the messages, work out the actual chronology, and summarise each real message once, in order - skip pure auto-replies (out-of-office, etc.) unless specifically asked about those. Don't just paste the raw AppleScript output.

Guardrails

  • Read-only, always. Never send, reply, forward, delete, move, flag, or mark anything read/unread via this skill.
  • Never search or summarise mail proactively - only when asked, for the specific thing that was asked about, right now.
  • If a search returns nothing, say so plainly rather than broadening the search silently - ask before trying a looser match.
  • Account/mailbox names are specific to how Mail.app is configured on your machine and can change (renamed, removed, email moves off Mail.app entirely) - if a search unexpectedly returns nothing that should be there, re-verify the account name rather than assuming the mail isn't there.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.