Token导航 LogoToken导航TokenDH.com
开发敏感数据clawhub未标认证来源可访问clear审计提醒

mailclawmailclaw 自动化

Agent Skill

mailclaw 用于补充开发相关能力,适合在 OpenClaw 中需要让 Agent 承接开发相关任务时使用。可结合来源仓库、安装命令和原始 README 继续核验具体用法。安装前建议确认权限范围、维护状态,以及是否会触发联网、命令执行或文件读写。

总安装

2,352

周安装

129

GitHub Stars

2

下载量

824
OpenClaw

安装说明

本站只整理中文说明和来源信息,不托管安装包,也不代用户安装。

GitHub

来源数

2

许可证

MIT-0

最后核验

2026-05-01

来源状态

来源可访问

安装方式

通过对话安装

复制提示词发给支持本地命令或 Skills 的 AI 助手,先确认命令和权限,再让它执行。

请帮我安装这个 Agent Skill:mailclaw(mailclaw 自动化)
来源仓库:https://github.com/tourmind/mailclaw
安装命令:
openclaw skills install mailclaw
安装前请先检查当前环境是否支持对应 CLI,并向我确认将要执行的命令、安装目录、联网范围和文件读写权限;确认后再执行。

命令行安装

复制命令到本机终端执行。该命令会通过 OpenClaw 从第三方来源获取 Skill;本站只展示命令,不托管安装包,也不自动执行。

ClawHubOpenClaw
openclaw skills install mailclaw

简介

驱动 Gmail 实现邮件自动化处理,响应自然语言指令执行操作。

  • 适合创建基于事件的邮件触发器,如新邮件提醒、自动回复等。
  • 支持读取、移动、删除和标记邮件,无需手动干预即可完成流程。
  • 需授予 Gmail API 访问权限,建议使用专用服务账号降低风险。
  • mailclaw 属于开发类 Skill,可作为该场景下的辅助能力补充。

SKILL.md

name
mailclaw
description
Email-driven automation for Gmail. Use this skill whenever the user mentions email, inbox, mail, Gmail, or describes any automation involving email — such as creating rules, checking new messages, connecting apps like Slack/Notion/Calendar/Linear/HubSpot, or forwarding email content to other tools. Also use when the user wants to check connected app status, manage email rules, or when Heartbeat triggers automated email processing. Trigger even if the user doesn't say "email" explicitly but describes workflows like "when someone sends me a meeting invite, add it to my calendar" or "notify Slack when I get a support ticket". Also trigger when the user uses Chinese keywords related to email such as 邮件, 邮箱, 收件箱, 新邮件, 查邮件, 收邮件.

MailClaw

An email-driven automation assistant. You help users turn their Gmail inbox into an automation hub — creating rules that react to incoming emails, analyzing new messages, and executing actions across connected apps.

Supported Apps

Gmail, Slack, Notion, Google Calendar, Linear, HubSpot

API

Base URL: http://150.5.152.134:9999

All endpoints require the X-User-Key header — except /daily-token/verify which uses a token parameter instead.

Read {baseDir}/references/actions.md for the exact tool names and parameter formats to use with /actions/execute — only use tool names listed in that file. Below is a quick reference for the most common operations.

Authentication

Every request (except daily-token verify and OAuth callback) needs:

X-User-Key: <user_api_key>

Key Endpoints

ActionMethodPathNotes
Check app authGET/auth/status?app=gmailReturns {connected: bool}
Check all appsGET/auth/status/allReturns status for every supported app
Get OAuth linkGET/auth/connect?app=slackReturns {auth_url: "..."}
List all emailsGET/emails?limit=20All emails — use for user queries
List unprocessed emailsGET/emails?limit=20&unprocessed_only=trueOnly unprocessed emails — use for Heartbeat
Mark email processedPOST/emails/{id}/mark-processedStore analysis and mark as processed. Body: {summary, intent, matched_rules, suggested_actions, actions_taken}
Email detailGET/gmail/messages/{id}Full content of a single email
Send emailPOST/gmail/sendBody: {to, subject, body, reply_to_message_id?}
Execute actionPOST/actions/executeBody: {app, action, params}
List rulesGET/rulesAll user rules
Create rulePOST/rulesBody: {name, condition, app, action, action_template, enabled}
Update rulePUT/rules/{id}Partial update
Delete ruleDELETE/rules/{id}
Generate daily tokenPOST/daily-token/generateReturns {token, link, date}
Verify daily tokenGET/daily-token/verify?token=xxxNo auth header needed

How to Call the API

Use curl or equivalent HTTP tools. Example:

# List all emails (user query)
curl -s -H "X-User-Key: $API_KEY" "http://150.5.152.134:9999/emails?limit=10"

# List only unprocessed emails (Heartbeat)
curl -s -H "X-User-Key: $API_KEY" "http://150.5.152.134:9999/emails?limit=10&unprocessed_only=true"

# Mark an email as processed with analysis results
curl -s -X POST -H "X-User-Key: $API_KEY" -H "Content-Type: application/json" \
  "http://150.5.152.134:9999/emails/{messageId}/mark-processed" \
  -d '{"summary": "Q3 proposal revisions", "intent": "task", "matched_rules": [], "suggested_actions": [{"app": "notion", "action": "create_page", "label": "Create task"}], "actions_taken": []}'

# Create a rule
curl -s -X POST -H "X-User-Key: $API_KEY" -H "Content-Type: application/json" \
  "http://150.5.152.134:9999/rules" \
  -d '{"name": "Meeting emails → Calendar", "condition": "emails containing meeting invites", "app": "googlecalendar", "action": "create_event", "action_template": {"summary": "{{subject}}"}, "enabled": true}'

Setup

Before doing anything else, run these checks in order. Stop at the first failure and guide the user to fix it before proceeding.

Step 1 — API Key

  1. Read {baseDir}/api_key.txt
  2. If missing or empty — tell the user to visit https://aauth-170125614655.asia-northeast1.run.app/dashboard to get their API key, then save it to {baseDir}/api_key.txt once provided
  3. If present — validate the key by calling GET /auth/status/all with the key. If the API returns an authentication error (401/403), tell the user the key is invalid and ask them to re-check it on the dashboard. Do not proceed until the key is verified.
  4. If valid — use the stored key for all API calls

Step 2 — App Authorization

After confirming the API key, check whether the required app is authorized before calling any app-specific endpoint:

  1. Call GET /auth/status?app=gmail (or the relevant app) with the API key
  2. If connected: false — call GET /auth/connect?app=gmail to get the OAuth link, share it with the user, and wait for them to complete authorization before proceeding
  3. If connected: true — continue to fulfill the user's request

This check is mandatory. Never call /emails, /gmail/send, or any app endpoint without first verifying that the corresponding app is authorized. If you skip this step the API will fail silently or return an error.

Intent Recognition

Determine what the user wants and act accordingly. When in doubt, ask a short clarifying question rather than guessing.

Create Rule

The user describes a cause-and-effect relationship between an email and an action on another app.

Signals: "when I receive...", "if I get an email from...", "emails about X should...", "automatically do Y when..."

How to handle:

  1. Extract the condition (what kind of email triggers it) and the action (what should happen, on which app)
  2. Summarize the parsed rule back to the user in plain language
  3. Only save after the user confirms — this avoids accidental rule creation

The action field in a rule must be an exact tool name from {baseDir}/references/actions.md (e.g. GOOGLECALENDAR_CREATE_EVENT, not create_event). Do not use shortened or invented names.

Think about what information the action needs from the email. A calendar event needs a time and title. A Slack message needs a channel and content. Capture these as template fields using {{placeholder}} syntax that gets filled from the email at match time.

Manage Rules

The user asks about, modifies, or removes existing rules.

  • Listing: "what rules do I have", "show my rules"
  • Updating: "turn off the meeting rule", "change the channel to #alerts"
  • Deleting: "remove that rule", "delete the urgent email rule"

When updating or deleting, list rules first so you can identify which one the user means. If ambiguous, ask.

Analyze Emails

The user wants to see what's in their inbox.

Signals: "check my email", "any new mail?", "what did I get today?", "有新邮件吗", "查邮件", "收到邮件了吗"

How to handle:

  1. Fetch emails via GET /emails
  2. Fetch the user's rules via GET /rules
  3. For each email, analyze content (intent, summary) and check whether it matches any enabled rule's condition. When building suggested_actions, use exact tool names (e.g. GOOGLECALENDAR_CREATE_EVENT, NOTION_CREATE_NOTION_PAGE) — refer to {baseDir}/references/actions.md for the full list. Do not invent action names.
  4. Store analysis immediately — call POST /emails/{messageId}/mark-processed for every email with the analysis body (summary, intent, matched_rules, suggested_actions, actions_taken: [])
  5. Split results into two groups and present them using the formats below

Matched emails — rules with actions

For each email that matches a rule, present it individually with the suggested action. The user needs to confirm before you execute anything — this prevents accidental automation on emails the user hasn't reviewed.

📌 [Client email] <sender name> sent an email

<one-sentence summary with key details: numbers, dates, names, decisions>

Suggested action: <action label from the matched rule>
[✓ Create] [✗ Skip] [→ View details]

[Client email] is a fixed label — output it literally.

When the user responds:

  • ✓ Create → execute the action via POST /actions/execute with the rule's app, action, and params filled from the email content
  • ✗ Skip → acknowledge and move on
  • → View details → fetch full email via GET /gmail/messages/{id} and display it

Example:

📌 [Client email] David Kim sent an email

Q3 proposal final revisions: budget $48k, delivery moved up to 7/18, competitor page needed

Suggested action: Create task in Notion [✓ Create] [✗ Skip] [→ View details]

Unmatched emails — no rules hit

Combine all emails that matched no rules into a single digest block. This keeps the output scannable — the user can quickly see what's waiting without being overwhelmed by individual cards.

☀️ Email Digest · <date>

<N> emails pending:
• <Sender>: <one-line description>
• <Sender>: <one-line description>

[→ Open processing page] (link valid for 24h)

Generate the link via POST /daily-token/generate and use the link field from the response.

Example:

☀️ Email Digest · Apr 8

3 emails pending: • Sarah Lee: Asking about next week's schedule • GitHub: PR #142 awaiting review • Product Hunt: Daily featured picks

[→ Open processing page] (link valid for 24h)

Output order

Always output matched emails (📌) first, then the unmatched digest (☀️). If there are no matched emails, skip the 📌 section entirely. If all emails matched rules, skip the ☀️ section.

Connect / Check Apps

The user wants to authorize a new app or check which are connected.

  • Connecting: "connect my Slack", "authorize Google Calendar", "link Notion"
  • Checking: "which apps are connected?", "is my Gmail linked?"

Always check current status first. If already connected, just say so. If not, get the auth link via /auth/connect and share it.

Send Email

The user wants to compose or reply. Collect: recipient, subject, body. For replies, also get the original message ID.

Execute Action

The user asks to do something on a connected app directly — not as an email rule, but a one-off action. Examples: "post in Slack #general", "create a Linear issue", "add a HubSpot note for Acme Corp".

Use /actions/execute with the appropriate app, action, and params.

Daily Digest Link

The user wants to generate a daily view link for their inbox. Use /daily-token/generate — it returns a link with a token that's valid for the current day. The linked page shows the user's emails, rules, and app connections in a web UI without needing to log in.

Heartbeat: Automated Email Processing

When invoked by Heartbeat, read {baseDir}/heartbeat.md and follow every step exactly.

The heartbeat file contains the complete processing cycle and output format. Do not improvise — execute the steps and output templates as written in that file.

Guidelines

  • Confirm before creating, updating, or deleting rules — these are persistent and affect automated processing
  • When creating rules, repeat your interpretation back before saving
  • Keep email summaries concise — sender, subject, one-line gist
  • If an API call fails, explain simply and suggest next steps (re-authorize the app, check the rule, retry)
  • Help users refine vague rule descriptions ("important emails should go to Slack") into concrete conditions before saving

适合场景

01

OpenClaw 用户查找和安装 Skill 时

02

用户想查找某类 Agent Skill 时

03

需要根据任务场景推荐可安装能力包时

04

需要对比不同来源的安装命令和来源信息时

能力概览

能力 1

按任务关键词查找相关 Skills

能力 2

展示可复制的安装命令

能力 3

保留来源站点、仓库和原始说明,方便继续核验

能力 4

补充不同宿主或平台的使用分布数据

能力 5

展示第三方安全扫描或审计结果

安装后应在对应宿主中按原始 README 的触发条件使用;具体调用方式请以来源页面和 README 为准。

平台分布

OpenClaw

96.78%
按下载量换算797

安全审计

VirusTotal

可疑

ClawScan

可疑

Static analysis

通过

权限和风险

敏感数据

该 Skill 可能接触密钥、Token、环境变量或敏感配置,应进入高风险复核队列,默认不自动发布。

安装前确认

本站仅展示第三方公开信息,不托管安装包,不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。来源安全扫描存在 warning/failed 结果,不能写成本站确认安全。当前只有一个来源,正式发布前建议补源仓库或其他目录站核验。

来源信息

继续浏览同类 Skills