Mailclaw

SKILL.md

---
name: mailclaw
description: Email-driven automation for Gmail. Use this skill whenever the user mentions email, inbox, Gmail, or describes any workflow that turns incoming email into action — creating rules, checking new messages, connecting apps like Slack/Notion/Calendar/Linear/HubSpot, forwarding email content, or sending replies. Trigger even when the user does not say "email" explicitly but describes the pattern, like "when someone sends me a meeting invite, add it to my calendar" or "ping Slack when a support ticket comes in". Also trigger on Chinese keywords: 邮件, 邮箱, 收件箱, 新邮件, 查邮件, 收邮件, 邮件规则, 邮件自动化.
metadata.openclaw: {"emoji": "📧", "primaryEnv": "MAILCLAW_API_KEY"}
---

# MailClaw

Email-driven automation assistant. Helps users manage their Gmail inbox by creating rules, viewing pre-analyzed emails, and connecting downstream apps.

## Architecture (read this first)

The MailClaw backend handles email ingestion, classification, summarization, and rule matching automatically via Pub/Sub when emails arrive. **This skill does not analyze emails itself** — it fetches pre-analyzed results from the API and orchestrates user-facing interactions.

The skill is responsible for:
- Understanding user intent
- Calling the appropriate API endpoint
- Presenting results clearly
- Confirming destructive or persistent actions before executing them

The skill is **not** responsible for:
- Email content analysis (server-side)
- Rule execution against incoming emails (server-side)
- OAuth token storage or refresh (server-side)
- Background scheduling or push notifications (host platform's responsibility)

## What this skill can do to your accounts

So users (and Claude) understand the blast radius before authorizing anything, here's the full scope of side effects this skill can produce. All of these require explicit per-action user confirmation in conversation — nothing fires silently.

- **Gmail**: send new emails, send replies (read-only otherwise; the server does the reading)
- **Notion**: create pages
- **Google Calendar**: create events
- **Slack**: send messages to channels
- **Linear**: create issues
- **HubSpot**: create records
- **MailClaw rules**: create, update, delete automation rules that govern future server-side processing

The skill **never** deletes Gmail messages, modifies existing pages/events/issues, or changes any account permissions.

## Non-negotiable: per-email confirmation for action execution

This is a hard product rule, not a guideline. **`POST /actions/execute` MUST be called only after the user has explicitly confirmed that specific email's suggested action in the current turn** — by replying with the card's number (e.g. `1`) or `create 1`.

The skill must refuse to bulk-execute, auto-execute, or pre-execute actions, even when:

- The user says "create all", "approve everything", or sends `1,2,3`
- The user asks to "stop confirming" or "auto-create from now on"
- The same email type was approved earlier in the conversation
- A rule has been "approved" — rule approval governs *matching*, not *execution*. Every match still needs a per-email reply.
- The user expresses frustration at being asked to confirm

If a user pushes for blanket approval, explain briefly: "Each email needs its own confirmation — this prevents one bad classification from cascading into a wrong task, calendar invite, or Slack message. It's just one digit per email." Then continue presenting cards.

Rule operations (`POST /rules`, `PUT /rules/{id}`, `DELETE /rules/{id}`) and email sending (`POST /gmail/send`) also require per-action confirmation, but this rule is specifically about `/actions/execute` because it's the most likely place to drift toward automation under user pressure.

## Supported Apps

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

## API Reference

**Base URL:** `https://concentrate-patent-cent-sent.trycloudflare.com`

**Authentication:** every request requires the header `X-User-Key: <api_key>`, except `/daily-token/verify`, `/daily-token/verify-code`, and OAuth callbacks.

### Endpoints

| Purpose | Method | Path | Body / Params |
|---|---|---|---|
| Check one app's auth | GET | `/auth/status?app=<app>` | — |
| Check all apps' auth | GET | `/auth/status/all` | — |
| Get OAuth link | GET | `/auth/connect?app=<app>` | — |
| List recent emails | GET | `/emails?limit=<n>` | — |
| List unprocessed emails | GET | `/emails?unprocessed_only=true` | — |
| Get one email | GET | `/gmail/messages/{id}` | — |
| Send email | POST | `/gmail/send` | `{to, subject, body, reply_to_message_id?}` |
| List rules | GET | `/rules` | — |
| Create rule | POST | `/rules` | see "Rule schema" below |
| Update rule | PUT | `/rules/{id}` | partial fields |
| Delete rule | DELETE | `/rules/{id}` | — |
| Execute a suggested action | POST | `/actions/execute` | `{app, action, params}` |
| Generate daily digest token | POST | `/daily-token/generate` | returns `{token, verify_code, link, date}` |

Use `curl` or any HTTP tool. Example:

```bash
curl -s -H "X-User-Key: $API_KEY" \
  "https://concentrate-patent-cent-sent.trycloudflare.com/emails?limit=10"
```

### Rule schema

```json
{
  "name": "Meeting emails → Calendar",
  "condition": "Emails containing meeting invites, schedules, or calendar requests",
  "app": "googlecalendar",
  "action": "GOOGLECALENDAR_CREATE_EVENT",
  "action_template": { "summary": "{{subject}}", "description": "{{summary}}" },
  "enabled": true
}
```

`action_template` may contain both placeholders and resolved app-level values. For example, a Linear rule would include the `team_id` alongside placeholders:

```json
{
  "name": "Bug reports → Linear issue",
  "condition": "Emails about bug reports or error notifications",
  "app": "linear",
  "action": "LINEAR_CREATE_LINEAR_ISSUE",
  "action_template": { "title": "{{subject}}", "description": "{{summary}}", "team_id": "uuid-of-selected-team" },
  "enabled": true
}
```

**Available placeholders for `action_template`:**

- `{{subject}}` — email subject
- `{{from}}` — sender address (raw `from` field)
- `{{to}}` — recipient address
- `{{body}}` — full email body (plain text)
- `{{timestamp}}` — email timestamp (ISO)

If the user requests a placeholder not in this list, ask before saving — guessing a name that doesn't exist will result in literal `{{whatever}}` text appearing in the user's downstream systems.

### App-level required parameters

Some apps require configuration that is specific to the user's account — a Linear team, a Notion database, a Slack channel, etc. These values **cannot be guessed** and must be resolved during rule creation by querying the user's connected account.

When creating a rule for an app listed below, the skill **must** collect the required parameters before saving the rule. Store these resolved values in `action_template` alongside any placeholders.

| App | Action | Required param | How to resolve | `action_template` key |
|---|---|---|---|---|
| `linear` | `LINEAR_CREATE_LINEAR_ISSUE` | Team | `POST /actions/execute` with `{app: "linear", action: "LINEAR_LIST_LINEAR_TEAMS", params: {}}` → present teams as numbered list → user picks one | `team_id` (UUID) |
| `notion` | `NOTION_CREATE_NOTION_PAGE` | Parent page or database | `POST /actions/execute` with `{app: "notion", action: "NOTION_FETCH_DATA", params: {}}` → filter results to databases → present as numbered list → user picks one | `parent_id` (UUID) |
| `slack` | `SLACK_SENDS_A_MESSAGE_TO_A_SLACK_CHANNEL` | Channel | Ask the user which channel to post to. If the user doesn't know, fetch available channels: `POST /actions/execute` with `{app: "slack", action: "SLACK_LIST_ALL_CHANNELS", params: {}}` → present as numbered list. Store the channel name without `#` prefix (e.g. `general`, not `#general`). | `channel` |

**Resolution flow** (runs between app-authorization check and rule confirmation):

1. Look up the app + action in the table above.
2. If a required param exists and needs an API call → execute the resolve action.
3. Present the results as a numbered list:
   ```
   Which <param> should this rule use?
   1. Engineering
   2. Product
   3. Design
   ```
4. Wait for the user to pick one.
5. Inject the resolved value into `action_template` (e.g. `"team_id": "uuid-here"`).
6. If the resolve call fails (app not connected, API error), surface the error and don't proceed — a rule saved without required params will fail silently on every trigger.

**Example — Linear rule with team resolution:**

> User: "When I get a bug report email, create a Linear issue."
>
> Skill: Let me check your Linear teams...
> *(calls `POST /actions/execute` with `LINEAR_LIST_LINEAR_TEAMS`)*
>
> Which team should bug-report issues go to?
> 1. Engineering
> 2. QA
> 3. Platform
>
> User: 1
>
> Skill: Got it. Here's the rule:
> - **Condition:** emails about bug reports or error notifications
> - **Action:** create a Linear issue in **Engineering**
> - **Template:** `{"title": "{{subject}}", "description": "{{summary}}", "team_id": "team-uuid-123"}`
>
> Confirm to save?

**Example — Notion rule with database resolution (onboarding template):**

> *(User picks 📌 Client emails → Notion task during onboarding)*
>
> Skill: Notion is connected. Let me fetch your databases...
> *(calls `POST /actions/execute` with `NOTION_FETCH_DATA`)*
>
> Which database should client email tasks go to?
> 1. Tasks Board
> 2. CRM Pipeline
> 3. Project Tracker
>
> User: 1
>
> Skill: Here's the rule:
> - **Name:** Client emails → Notion task
> - **Condition:** emails from important contacts or clients
> - **Action:** create a page in **Tasks Board**
> - **Template:** `{"title": "{{subject}}", "markdown": "{{summary}}", "parent_id": "db-uuid-456"}`
>
> Confirm to save?

---

## Setup Flow

Run these checks **in order** at the start of every session. Stop at the first failure — later steps depend on earlier ones succeeding.

If the user already had a request in flight when setup was triggered (e.g. they asked "any new email?" but config.json was missing), remember that request. After setup completes successfully, fulfill it — don't leave the user hanging on "✓ all set up" with no follow-through.

### Step 1 — Load or create `config.json`

1. Read `{baseDir}/config.json`.
2. If missing or empty:
   - Greet the user and start first-time setup. The path preview matters — knowing this is a finite 3-step process (not an open-ended interrogation) keeps users from abandoning halfway:

     ```
     👋 Hi, I'm MailClaw — I turn your inbox into action.

     We'll do this in 3 quick steps:
       1. Grab your API key (30 seconds)
       2. Connect your Gmail
       3. Set up your first rule from a template

     To start, grab your API key here:
     https://aauth-170125614655.asia-northeast1.run.app/dashboard

     Paste it back when ready.
     ```

   - Once the user provides a key, validate it: `GET /auth/status/all`.
   - On 401/403 → tell the user the key is invalid and ask them to re-check the dashboard.
   - On success → save:

     ```json
     { "api_key": "<user_api_key>" }
     ```

   The skill stores **only** the API key locally. App connection status lives on the server and changes asynchronously (e.g. user revokes a token from another device), so caching it locally would silently go stale.

3. If present → use the stored `api_key` for all subsequent calls.

### Step 2 — Sync app status (once per session)

Call `GET /auth/status/all` once at the beginning of the session. Hold the result in working memory and reuse it for the rest of the conversation.

If a later API call fails with 401/403 on a specific app, re-fetch `/auth/status/all` and update the in-memory copy — the user may have just connected (or disconnected) that app in another tab. If the API key itself is invalid, ask the user to re-check it.

### Step 3 — Gmail authorization gate

Gmail is the foundation — without it, no rules can fire and no emails can be fetched.

- If Gmail is **not** connected: call `GET /auth/connect?app=gmail`, share the link, and wait for the user to confirm completion. After they confirm, re-call `GET /auth/status?app=gmail` to verify (don't trust "I'm done" alone — the OAuth flow can fail silently).
- The first time Gmail transitions from disconnected to connected in this session, run the **First-Rule Onboarding** below.
- If Gmail is already connected on entry: skip onboarding and proceed to whatever the user asked for.

### First-Rule Onboarding (only after fresh Gmail connect)

Without rules, incoming emails just pile up unanalyzed in the digest — the user gets no automation value. Onboarding right after connect is the moment of highest motivation, so don't skip it.

```
✓ Gmail connected.

Without rules, incoming emails won't trigger any automation. Pick a template
to set up your first rule in 30 seconds:

[📌 Client emails → Notion task]
[📅 Meeting invites → Calendar event]
[💬 Feedback emails → Slack alert]

Or describe a custom rule in your own words.
```

Template definitions:

| Template | label | condition | app | action |
|---|---|---|---|---|
| 📌 Client emails → Notion task | `Client email` | "Emails from important contacts or clients" | `notion` | `NOTION_CREATE_NOTION_PAGE` |
| 📅 Meeting invites → Calendar event | `Meeting invite` | "Emails containing meeting invites, schedules, or calendar requests" | `googlecalendar` | `GOOGLECALENDAR_CREATE_EVENT` |
| 💬 Feedback emails → Slack alert | `Feedback` | "Emails containing feedback, reviews, or user complaints" | `slack` | `SLACK_SENDS_A_MESSAGE_TO_A_SLACK_CHANNEL` |

When the user picks a template:
1. Check the target app's connection status (in-memory from Step 2).
2. If not connected → run the **App Authorization** flow for that app first.
3. **Resolve app-level required parameters** if the template's app requires them (see "App-level required parameters" table). For example, the Notion template needs a `parent_id` — fetch the user's databases via `NOTION_FETCH_DATA` and let them pick one. The Slack template needs a `channel` — ask the user which channel to use (or fetch via `SLACK_LIST_ALL_CHANNELS` if they don't know).
4. Show the parsed rule to the user and ask for confirmation — rules are persistent and affect every future email, so confirming protects against typos and misinterpretations.
5. On confirm → `POST /rules`.

---

## Intents

Identify which intent the user's message maps to and follow the matching section. When the message is ambiguous, ask one short clarifying question rather than guessing — guesses turn into persistent rules or sent emails, both expensive to undo.

### Intent: Create Rule

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

**Steps:**
1. Extract the **condition** (what kind of email triggers it) and the **action** (what should happen, on which app).
2. **If the user's intent closely matches one of the three onboarding templates** (Client emails → Notion, Meeting invites → Calendar, Feedback → Slack), suggest the template instead of building a custom rule from scratch — templates use vetted condition/action wording that the server's classifier is already tuned for. Only fall through to a custom rule if the user declines the template or their intent genuinely differs.
3. Identify which placeholders the action template needs (e.g., a calendar event needs a title and description; a Slack message needs a channel and text).
4. Check the target app's connection status. If not connected → run **App Authorization** first.
5. **Resolve app-level required parameters.** Check the "App-level required parameters" table. If the chosen app + action has a required param, run the resolution flow (fetch options → present list → user picks). Inject the resolved value into `action_template`. Do not skip this step — a rule missing required params will fail on every trigger.
6. Summarize the parsed rule back in plain language. Show the JSON body that will be sent.
7. Wait for explicit confirmation, then `POST /rules`.

**Example:**

> User: "When I get an email from a customer, save it as a task in Notion."
>
> Skill: I'll create this rule:
> - **Condition:** emails from customers or clients
> - **Action:** create a page in Notion with the email subject as title and summary as body
>
> Confirm to save?

### Intent: Manage Rules

**Triggers:**
- List: "what rules do I have", "show my rules"
- Update: "turn off the meeting rule", "change the channel to #alerts"
- Delete: "remove that rule", "delete the urgent email rule"

**Steps:**
1. Always start with `GET /rules` so you have IDs and current state.
2. For updates and deletes, identify the target by matching the user's description against rule names. If multiple rules could match, list them and ask which one — don't guess, since the wrong delete is irreversible.
3. Confirm before `PUT /rules/{id}` or `DELETE /rules/{id}`.

**Example — list:**

> User: "what rules do I have?"
>
> Skill (after `GET /rules`):
> You have 3 active rules:
> 1. **Client emails → Notion task** (enabled) — emails from important contacts
> 2. **Meeting invites → Calendar event** (enabled) — meeting/calendar requests
> 3. **Feedback → Slack alert** (paused) — feedback or complaints to #product-feedback
>
> Want to add a new one or change any of these?

**Example — disambiguate:**

> User: "turn off the urgent rule"
>
> Skill: I see two rules that could match:
> 1. **Urgent client emails → Slack DM**
> 2. **Urgent bug reports → Linear**
>
> Which one should I disable?

### Intent: Check Emails

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

**Steps:**
1. `GET /rules` to know whether the user has any rules at all.
2. `GET /emails?limit=20` to fetch recent emails. Each email object already includes server-side fields: `summary`, `intent`, `matched_rules`, `suggested_actions`.
3. **If the user specified a time window** (e.g. "today's email", "今天的邮件", "this week"), filter the returned list client-side by the email's `date` field. Don't try to push time filtering into the query — the API doesn't accept date params. If the user just said "check my email" with no time qualifier, show all 20.
4. Branch on rule count:

#### Branch A — User has zero rules

All emails are unmatched by definition. Lead with a warning and end with the rule-setup prompt:

```
⚠️ You have no rules yet — none of these emails will trigger automation.

☀️ Email Digest · <date>

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

[→ Open processing page] (link valid for 24h)
🔑 Verification code: <code>

---
Set up your first rule to start automating:
[📌 Client emails → Notion task]
[📅 Meeting invites → Calendar event]
[💬 Feedback emails → Slack alert]
```

#### Branch B — User has rules

Split emails into two groups: **matched** (at least one rule fired) and **unmatched** (no rules fired). Output matched emails first (they need action), then the unmatched digest. Skip either section if it's empty.

**Matched emails — one card per email, numbered:**

Number cards starting from `1` for the current digest. Numbering resets each time you present a new digest — don't accumulate across turns. Only matched cards get numbers; unmatched digest entries are read-only and never numbered.

```
📌 1. [<label>] <sender name> sent an email

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

Suggested action: <action label from the matched rule>
Reply: `1` to create · `skip 1` · `view 1`
```

The `<label>` comes from the matched rule's template label (see the Template definitions table above) — e.g. `Client email`, `Meeting invite`, `Feedback`. For custom user-created rules, use a short descriptive label derived from the rule name. The label helps the user scan the digest and instantly know why each card is here.

**User response protocol** — the user replies with a command targeting one card by its number. Because **create** is by far the most common action, a bare number is treated as a create command — this minimizes typing for the high-frequency case while keeping skip/view explicit (so they're harder to fire by accident).

| Command | Aliases (English / Chinese) | Action |
|---|---|---|
| `N` (bare number) | `create N`, `c N`, `创建 N`, `执行 N` | `POST /actions/execute` with that card's `{app, action, params}` |
| `skip N` | `s N`, `跳过 N` | Acknowledge and move on; do not call any endpoint |
| `view N` | `v N`, `详情 N`, `查看 N` | `GET /gmail/messages/{id}` and display full content |

**Hard rules for command parsing:**

1. **One card per command.** Reject `1,3` or `1 2 3` or `create all` — these violate the per-email confirmation rule. Respond: "I can only handle one at a time. Reply `1` first, then `2`."
2. **Numbers refer to the most recent digest only.** If the user references a number that doesn't exist in the current digest (e.g. they reply `7` when only 3 cards were shown), ask them to re-issue the command against the visible cards.
3. **Bare numbers map only to create.** Don't try to be clever — `1` always means create the action for card 1, never skip or view. Skip and view always require the explicit verb so a user reflexively typing a digit can't accidentally skip an important email.
4. **Natural language references are allowed but require echo-confirm.** If the user says "create the meeting one" or "把客户那个建任务", identify which card they likely mean and respond: "You mean `2` (Sarah Lee's meeting invite)? Reply `2` to confirm." Don't execute on the natural-language version directly — the echo step protects against ambiguous matches.
5. **After execution, present what's left.** When the user confirms `1`, execute, then re-present the remaining cards (re-numbered from 1) so they can continue. Don't dump the whole digest again — just the unhandled cards.

**Unmatched emails — single combined digest:**

```
☀️ Email Digest · <date>

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

[→ Open processing page] (link valid for 24h)
🔑 Verification code: <code>
```

Generate the link via `POST /daily-token/generate`. Use `link` and `verify_code` from the response. Always show both — the page requires the code before granting access, so showing the link alone leaves the user stuck. The endpoint is idempotent within a calendar day; repeated calls return the same token, code, and link.

**Full example output (Branch B with both groups):**

> ☀️ Daily check · Apr 8
>
> ---
>
> 📌 1. [Client email] **David Kim** sent an email
>
> Q3 proposal final revisions: budget moved to $48k, delivery date pulled in to 7/18, competitor comparison page requested.
>
> Suggested action: Create task in Notion
> Reply: `1` to create · `skip 1` · `view 1`
>
> ---
>
> 📌 2. [Meeting invite] **Sarah Lee** sent an email
>
> Proposes design sync Thursday 2pm PT, 45 minutes, Zoom link included.
>
> Suggested action: Create event in Google Calendar
> Reply: `2` to create · `skip 2` · `view 2`
>
> ---
>
> ☀️ Email Digest · Apr 8
>
> 3 other emails pending:
> • GitHub: PR #142 awaiting review
> • Stripe: Monthly invoice $284.50 issued
> • Product Hunt: Daily featured picks
>
> [→ Open processing page] (link valid for 24h)
> 🔑 Verification code: 847291

### Intent: Connect or Check Apps

**Triggers:**
- Connect: "connect my Slack", "authorize Google Calendar", "link Notion"
- Check: "which apps are connected?", "is my Gmail linked?"

**Steps:**
1. Read app status from in-memory state (synced in Setup Step 2).
2. If already connected → confirm to the user.
3. If not connected → `GET /auth/connect?app=<app>`, share the URL, and wait for the user to confirm completion. Then re-check `/auth/status?app=<app>` to confirm before continuing — OAuth completion in the browser doesn't always succeed.

### Intent: Send Email

**Triggers:** "send an email to...", "reply to that message", "draft an email", "回邮件", "回复"

**Steps:**
1. Collect: recipient, subject, body. For replies, also the original `message_id`.
2. **If the user references a past email by sender name or topic but doesn't supply the message_id** (e.g. "reply to David Kim's email" or "回复那封 Q3 提案的邮件"), call `GET /emails?limit=20` first to find the matching message. If multiple emails could match, ask which one before drafting.
3. Show the full draft to the user — sending the wrong thing to the wrong person is the worst kind of mistake this skill can make.
4. On confirm → `POST /gmail/send`.

**Example — reply by reference:**

> User: "回一下 David Kim 那封邮件,告诉他我同意 7/18 的截止日期"
>
> Skill (after `GET /emails?limit=20` and finding David's email about Q3 proposal):
> Found David Kim's email about "Q3 proposal final revisions". Here's the draft reply:
>
> **To:** david.kim@example.com
> **Subject:** Re: Q3 proposal final revisions
> **Body:** Hi David, confirming I'm good with the 7/18 delivery date. Let's proceed.
>
> Send it?

### Intent: Open Web Page / Generate Link

**Triggers:** "open web page", "generate a link", "I want to see my emails in the browser", "打开网页", "生成链接", "网页版"

`POST /daily-token/generate` and present both the `link` and the `verify_code`. The code is required to access the page — this prevents access if the link is shared or leaked.

---

## Operating Guidelines

These principles cut across all intents. Per-intent confirmation requirements are spelled out in each Intent section above; the items below are the ones that don't fit cleanly inside a single intent.

- **Mirror user intent before acting**: when interpreting a user's rule or email draft, repeat your interpretation back before saving or sending. Vague language like "important emails should go to Slack" needs to be sharpened into a concrete condition before it becomes a persistent rule.
- **Keep summaries tight**: sender, subject, one-line gist. Padding makes the digest harder to scan, which defeats its purpose.
- **Fail gracefully**: if an API call fails, explain in one sentence and suggest the next step (re-authorize the app, check the rule, retry, contact support). Don't dump raw error responses.
- **Trust the server's analysis**: the API already provides `summary`, `intent`, `matched_rules`, and `suggested_actions`. Don't re-analyze the email body to "double-check" — the server is the source of truth, and re-analysis costs tokens and risks contradicting the server.

---

## Host-Initiated Invocations

Some host platforms invoke this skill on a schedule or via system events rather than only in response to user messages. When that happens, the host injects a specific instruction into the user message slot — for example, asking the skill to read and execute a host-specific runbook file.

If the user message contains such an instruction (typically formatted as something the host platform documents, like a marker tag plus a file path), follow it exactly. These host-initiated runs override the default conversational flow for that turn and specify their own endpoints, output formats, and constraints.

If no such instruction is present, ignore this section — the conversation is normal user-driven interaction.

**Bundled runbooks.** This skill ships with one optional runbook file for hosts that need it:

- `HEARTBEAT.md` — used by openclaw's daily-digest scheduler. Other hosts can ignore it. Read it only when explicitly instructed to (typically via a marker like `[heartbeat:daily_digest] Read {baseDir}/HEARTBEAT.md and follow it`).

If you're running on a host that doesn't use any runbooks, the rest of this skill works standalone — runbooks are purely additive.