Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →sonichi/email-find
Locate a specific email when the obvious searches fail.
Passed 12 of 19 test cases with the skill, and 6 of 19 without it.
and 7 more in the full report
8 fixed6 passed either way7 still failing1 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 7 test cases the skill fixed. Same model, same prompt, with and without the skill.
Phase 1 search identified candidate thread 187a2b4c5d for the audit discussion, but the snippet is truncated. Which parameter value must be supplied when re-fetching the thread to read full message bodies?
| Checked | Without skill | With skill |
|---|---|---|
| Specifies messageFormat: "FULL_CONTENT" when re-fetching the thread. | Missed | Passed |
The instructions your model reads when the skill loads.
A playbook for finding a specific email through the Gmail MCP (claude.ai Gmail) when the obvious search query returns nothing. Optimized for the case where the user describes an email and the agent must not give up easily.
Usage: /email-find <description>
ARGUMENTS: $ARGUMENTS
If the user is confident an email exists, the email exists. Do not respond with "I can't find it" after one or two failed queries. The default failure mode is the agent's query, not the user's memory.
Broad before narrow. Always run at least one query that scans the full inbox by recency before narrowing on subject or sender keywords. A reply about Topic-X can land on a thread whose subject names a different topic, with zero topic-X tokens in the subject — a keyword filter throws those threads away.
Expand sender to partners, not just the named entity. When the user mentions a customer / vendor / collaborator by name, also search for known associated email domains. Operational replies often come from data-ops partners, contractors, or assistants — not the named principal contact.
Re-fetch threads in full. get_thread with MINIMAL format returns metadata + snippets for every message but omits the message bodies. If you've identified the candidate thread and need to read what was actually written, fetch it again with FULL_CONTENT. The search-result preview in the UI may also truncate long threads; FULL_CONTENT exposes everything.
Show the search trail. End every "found it" or "still hunting" reply with the list of queries you tried, so the user can see what worked and what didn't.
In the queries below, me is Gmail's reserved keyword for the authenticated user's primary address — works for everyone regardless of which account is connected.
Run one broad query first to anchor on what's actually in the inbox in the relevant time window:
search_threads query="(to:me OR from:me) newer_than:Nd" pageSize=15
Where N covers the window the user cited (default 2; cite-driven). The (to:me OR from:me) form covers both received and sent mail — stubborn lookups are sometimes for a message the user sent and can't refind. Look at the actual returned threads — note senders, subjects, dates. Often the email is already in the top 10 results, just with a subject you wouldn't have guessed.
If Phase 1 didn't surface it, run one query per partner domain the user may have meant. Look up known partner domains for the named entity in ## Per-user partner-domain memory below. For each, format:
search_threads query="from:DOMAIN OR from:NAMED-ADDRESS" pageSize=10
test cases passed, vs 6 / 19 without
More skills from the same source and nearby in the registry, with their headline benchmark lift.