菜单
Triage Gmail inbox by labeling, starring, and archiving emails. Also creates filters for recurring senders. Use this skill whenever the user mentions email triage, inbox cleanup, email labels, email filters, or wants to process their inbox. Default mode is triage.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Training plan scheduling, weekly retrospectives, and training adjacent constraint validation. Use this skill whenever the user mentions training, lifts, runs, climbs, the Friday long run, sauna timing, cold plunge timing, recovery days, cutback weeks, altitude weeks, race week, training restructure, Fitbod, asking to schedule a training session, or asking to look back / retrospect on a past training week. Also trigger for "/assist:plan-training", "schedule my long run", "what does training look like this week", "how did last week go", "training retro", or any request that touches the training plan in `Constitution/Fitness/`. Independently usable, and also called by `/assist:plan-week` during Monday planning.
Weekly planning, calendar management, and Monday morning task slotting. Use this skill whenever the user mentions weekly planning, the Monday planning session, slotting tasks, finding free time, checking what their week looks like, moving or swapping calendar events, or wants help fitting something into their week. Also trigger when the user asks about V2MOM measure coverage. Training plan scheduling lives in `assist:plan-training` and meal planning in `assist:plan-meals`; this skill calls into both during Monday planning.
Audit and redesign the context architecture (every CLAUDE.md, learned-rules.md, and tool doc that loads into Claude Code sessions) so load-bearing rules are surfaced and enforced at the point of use rather than scattered, duplicated, or buried. Use this skill whenever Forni says "groom context", "groom-context", "we forgot a basic again", "the context is sprawling", "the rules keep getting lost", "clean up the context", or invokes "/assist:groom-context". Also invoked as a closing step by the monthly path of assist:reflect. This is the cleanup counterpart to assist:codify-context, which writes knowledge into the same architecture.
Craft Business Development emails for RYLLC fractional CTO consultancy. Handles warm reconnects, job posting outreach, rejection follow-ups, VC intros, and custom BD scenarios. Uses established templates and project voice.
Codify knowledge from the current session into the appropriate location in the context architecture using progressive disclosure. Use this skill whenever the user says "codify" followed by a topic, wants to capture something they just figured out, asks to document a pattern or convention, or says something like "we should write this down" or "future me needs to know this." Also trigger when the user discovers a gotcha, foot-gun, or non-obvious behavior worth preserving. Works for both project directories (three-layer CLAUDE.md/README.md pattern) and skill directories (Learned Rules in SKILL.md). Named after the "plan, delegate, assess, codify" Level 4 compounding loop. This is the write-in counterpart to `assist:groom-context`, which audits and prunes the same context architecture.
Analyze job roles for fit, draft application question responses, find hiring managers, and create follow-up emails for RYLLC job applications. Focuses on climate tech IC product/SRE roles.
| name | assist:emails |
| description | Triage Gmail inbox by labeling, starring, and archiving emails. Also creates filters for recurring senders. Use this skill whenever the user mentions email triage, inbox cleanup, email labels, email filters, or wants to process their inbox. Default mode is triage. |
| argument-hint | [triage | filters] |
| allowed-tools | ["Bash","mcp__claude_ai_Notion__*","mcp__claude_ai_Google_Calendar__*","mcp__claude_ai_Todoist__*","Read","Edit","Write","AskUserQuestion","WebFetch"] |
Triage the Gmail inbox and create filters for recurring senders. All Gmail operations use the gws CLI.
Read learned-rules.md for prior corrections (these override defaults)
Read triage-rules.md and label-map.md for classification rules
Resolve label name -> ID mapping:
gws gmail users labels list --params '{"userId":"me"}' --format json 2>&1 | grep -v "^Using"
All Gmail operations go through the gws CLI via Bash. Every command emits Using keyring backend: keyring to stderr; always filter with 2>&1 | grep -v "^Using" before piping to JSON parsers.
# Authoritative inbox list (use this, NOT +triage, for the canonical set)
gws gmail users messages list --params '{"userId":"me","q":"in:inbox","maxResults":50}' --format json
# Read email body
gws gmail +read --id <MESSAGE_ID>
# Get message metadata (headers like List-Unsubscribe, From, Subject)
gws gmail users messages get --params '{"userId":"me","id":"<ID>","format":"metadata","metadataHeaders":["From","Subject","Date","List-Unsubscribe"]}' --format json
# Modify labels on a single message
gws gmail users messages modify --params '{"userId":"me","id":"<ID>"}' --json '{"addLabelIds":["<LABEL_ID>"],"removeLabelIds":["INBOX","UNREAD"]}'
# Batch modify labels on multiple messages
gws gmail users messages batchModify --params '{"userId":"me"}' --json '{"ids":["<ID1>","<ID2>"],"addLabelIds":["<LABEL_ID>"],"removeLabelIds":["INBOX","UNREAD"]}'
# Send an email (used for unsubscribe)
gws gmail +send --to "<address>" --subject "<subject>" --body "<body>"
# Create a draft reply within a thread
gws gmail users drafts create --params '{"userId":"me"}' --json '{"message":{"threadId":"<THREAD_ID>","raw":"<BASE64_RFC2822>"}}'
Get the authoritative inbox via gws gmail users messages list with q=in:inbox. For each message, fetch headers (From, Subject, Date) to classify. Cross-reference against triage-rules.md and learned-rules.md.
Partition messages into four buckets:
Batch modify all high-confidence matches without asking. Use batchModify for efficiency. Only auto-process when classification confidence is high: exact sender match in triage-rules.md/learned-rules.md or unambiguous subject pattern. If there is any ambiguity, move the email to Phase 4 instead.
📑 Admin/🛒 Purchases label, remove INBOX and UNREAD📑 Admin/🏷 Offers label, remove INBOX and UNREADReport the count and a one-line summary of what was auto-processed after all phases complete.
Family emails always come first. For each:
gws gmail +read --id <ID>🤝 Community/👨👩👦👦 Family. Yellow star, or red star if >3 days oldPresent each email individually via AskUserQuestion. For each email show:
The user can:
When the user corrects a classification, append the new rule to learned-rules.md under the appropriate section. Include enough context so the rule is useful in future sessions.
After all new emails are processed, acknowledge emails that remain in the inbox from prior triage sessions (they have labels and stars already). Present a brief summary: count and list of senders/subjects. Do not re-process these unless the user asks.
Multi-label routing: Emails can take multiple labels. An Anthropic receipt is both 📑 Admin/🛒 Purchases and 🛠️ Craft/💻 Development. Always route to the most specific sublabel, never a parent pillar alone.
Star assignment: Apply colored stars via system label IDs. Never star emails that get archived. Star meanings follow the governing "Star semantics" rule in learned-rules.md (Behavior Rules); that rule is the single source of truth for which star means what.
When in doubt, ask: If there is any ambiguity about classification, or an email could take multiple labels, ask the user via AskUserQuestion. Do not guess. Defaulting to asking is always correct.
Drafting replies: Never send emails directly to people. Always create a draft, present it for review, and wait for explicit approval to send. Direct sends are acceptable when emailing an automation, robot, or mailing list (e.g., an unsubscribe mailto address). Never reference people or sources the user does not know. Always read full email content before making assumptions.
Calendar awareness: When someone proposes a date/time, check the calendar to see if it works. If it does, help draft an acceptance and offer to send an invite. If not, propose an alternative (prefer Fridays for in person meetings).
When the user requests unsubscribe during one-by-one presentation:
Fetch the List-Unsubscribe header:
gws gmail users messages get --params '{"userId":"me","id":"<ID>","format":"metadata","metadataHeaders":["List-Unsubscribe"]}' --format json
If a mailto: address is found, send an unsubscribe email:
gws gmail +send --to "<unsubscribe-address>" --subject "Unsubscribe" --body "Unsubscribe"
If only a URL is found, present the URL to the user and note they need to visit it manually
If no List-Unsubscribe header exists, inform the user that no automated unsubscribe is available
After the unsubscribe action, label and archive the triggering email as normal
Some emails trigger actions outside Gmail. Track these as pending items per email. Do not archive an email until all its external actions are complete. If a tool fails (e.g., auth error), prompt the user to fix it before proceeding.
Supported action types:
mcp__claude_ai_Notion__notion-fetch to get the current page content, then mcp__claude_ai_Notion__notion-update-page to add the link. Example: Claude Team announcement emails get linked on the AI Research page.Create Gmail server-side filters for high-frequency senders.
Read learned-rules.md for any previously created filters (stored under ## Created Filters)
Analyze learned rules and recent triage to identify candidates
Skip any sender that already has a filter recorded in learned-rules.md
Propose filters to user via AskUserQuestion, one at a time
Create approved filters:
gws gmail users settings filters create --params '{"userId":"me"}' --json '{"criteria":{"from":"<sender>"},"action":{"addLabelIds":["<LABEL_ID>"],"removeLabelIds":["INBOX"]}}'
Default action: apply appropriate label, mark read, skip inbox
After creating a filter, record it in learned-rules.md under ## Created Filters to prevent duplicates