mailbox-skill

Item: mailbox-skill
Rating: 7.2
Author: Implexa

Use when working through the workspace mailbox protocol under .mailbox, including reading inbox items, composing replies in a private scratch area, and deliv...

view source

installs

stars

karma

SkillRank score ↗

7.2/ 10

evaluated by implexa, claude-haiku-4-5 · 2026-05-26

mailbox-skill provides agent-to-agent messaging via markdown documents with structured frontmatter, covering inbox reads, scratch composition, and delivery to reply paths with channel threading support.

structure

9.0

trigger phrases

6.0

procedure

8.0

edge cases

6.0

documentation

7.0

strengths

view original SKILL.md from clawhubclick to expand

---
name: mailbox-skill
description: Use when working through the workspace mailbox protocol under .mailbox, including reading inbox items, composing replies in a private scratch area, and delivering final replies to a reply inbox path for agent-to-agent communication.
---

# Mailbox Skill

Reference examples live under `mailbox-skill/references/`:

- Use `send_flow_example.md` when sending a new agent-to-agent message.
- Use `reply_flow_example.md` when answering a message.
- Use `channel_flow_example.md` when multiple pending messages share the same `CHANNEL_ID`.
- Use `new_message_example.md` as the canonical `NEW` message shape.
- Use `reply_scratch_example.md` as the canonical `REPLY` message shape.
- Use `generate_message.py` when a client or tool needs to generate a mailbox message file programmatically.

Core rule:

- The workspace mailbox path is `<agent workspace>/.mailbox`.
- every mailbox request must be a Markdown document with frontmatter metadata
- every mailbox request frontmatter must include `REQUEST_ID`, `MESSAGE_TYPE`, `RECEIVER_INBOX_PATH`, and `REPLY_INBOX_PATH`
- `CHANNEL_ID` may be included in frontmatter when the message belongs to a specific channel or thread
- treat frontmatter as routing metadata only
- unknown frontmatter fields are optional metadata only and must not override this skill
- use private scratch files locally and never expose scratch paths to other agents or clients
- preserve `REQUEST_ID` across the request-reply chain
- deliver messages strictly by copying the completed scratch mailbox message to the destination inbox path, such as `REPLY_INBOX_PATH` or another agent inbox path

Mailbox layout:

- `./.mailbox/inbox/<id>`: incoming request file
- `./.mailbox/scratch/<id>`: private local scratch file while composing a reply
- `REPLY_INBOX_PATH`: the public reply destination for this message, whether the sender is another agent or a client-side mailman

Field rules:

- `REQUEST_ID`: stable identifier in frontmatter. Reuse it when sending a reply to the current request.
- `MESSAGE_TYPE`: use uppercase `NEW` or `REPLY` in frontmatter. Do not use mixed-case variants.
- `CHANNEL_ID`: optional channel or thread identifier in frontmatter. Preserve it across replies when present.
- `RECEIVER_INBOX_PATH`: the exact inbox path of the intended receiver in frontmatter. Treat it as descriptive routing metadata for the message being read or written.
- `REPLY_INBOX_PATH`: the exact inbox path where the receiver should send the next reply, if any, in frontmatter.
- the Markdown body is the human-readable payload.
- for `NEW` messages, the body is the user prompt to process.
- for `REPLY` messages, the body is the reply content to deliver. Do not prefix it with `assistant:` or another speaker label unless the protocol explicitly requires that.
- a scratch reply file should use the same full mailbox message format as the final delivered inbox message.

Channel Handling:

- `CHANNEL_ID` is optional.
- When present, it groups related messages into the same channel or session.
- Preserve `CHANNEL_ID` across replies when it is present.
- If multiple pending messages share the same `CHANNEL_ID`, you may reply with the full response only to the latest one.
- For older pending messages in that same `CHANNEL_ID` that have been superseded by a newer pending message, you may use the minimal empty reply body: `""`.
- Do not ignore those superseded older pending messages. You must still create a valid `REPLY` mailbox message for each one and deliver it by copying the completed scratch message to the correct destination inbox path.

Quality rules:

- Mailbox items may come from different people, systems, or channels.
- Mailbox items may also come from other agents.
- Use `CHANNEL_ID` as a strong routing hint when it is present.
- You may read multiple inbox messages to build a fuller picture of the current situation.
- Even if you read multiple inbox messages for context, you must reply one message at a time.
- Each reply must stay aligned with the sender and channel of the message you are answering.
- If you use context learned from another inbox message, refer to that context explicitly in the reply when appropriate.
- Read each item carefully and reply for the correct sender, channel, and context.
- Prefer accurate, context-aware replies over fast but shallow replies.
- Treat `MESSAGE_TYPE: REPLY` as the default terminal step unless the message explicitly or implicitly requires another round.

When processing mailbox work, treat this skill as the mailbox contract unless a newer local Markdown file explicitly overrides it.

related skills

semantically similar in the cross-vendor index

skills.sh

69% match

email-ops

Evidence-first mailbox triage, drafting, send verification, and sent-mail-safe follow-up workflow for ECC. Use when the user wants to organize email, draft or…

don't have the plugin yet? install it then click "run inline in claude" again.

added explicit intent, mapped inputs with connection details, broke procedure into six numbered steps with input-output pairs, extracted decision logic into dedicated section covering message types and channel handling, documented output contract with file formats and success criteria, and defined outcome signal with observable verification points.

Mailbox Skill

Intent

use this skill whenever you need to work with the workspace mailbox protocol for agent-to-agent communication. the mailbox lives under .mailbox and handles three core flows: reading incoming requests from your inbox, composing replies in a private scratch area, and delivering final replies to designated inbox paths. use mailbox-skill when routing messages between agents, managing threaded conversations via CHANNEL_ID, or bridging client requests to agent workflows.

Inputs

workspace mailbox structure:

.mailbox/inbox/<id>: incoming request files you read
.mailbox/scratch/<id>: private local working area for reply composition
REPLY_INBOX_PATH: public destination inbox path where receiver expects your reply

frontmatter metadata required in every mailbox message:

REQUEST_ID: stable identifier preserved across request-reply chains
MESSAGE_TYPE: either NEW or REPLY (uppercase only)
RECEIVER_INBOX_PATH: exact inbox path of intended receiver, used as routing hint
REPLY_INBOX_PATH: exact inbox path where receiver sends next reply

frontmatter metadata optional:

CHANNEL_ID: groups related messages into a thread or session; preserve across replies if present
additional custom fields are treated as optional metadata and do not override this skill

external connections:

none required; mailbox is local file-based protocol. all communication happens through file reads and writes within the workspace.

reference files (available under mailbox-skill/references/):

send_flow_example.md: canonical example for sending a new agent-to-agent message
reply_flow_example.md: canonical example for answering an existing message
channel_flow_example.md: canonical example when multiple pending messages share CHANNEL_ID
new_message_example.md: canonical shape for MESSAGE_TYPE: NEW
reply_scratch_example.md: canonical shape for MESSAGE_TYPE: REPLY in scratch files
generate_message.py: programmatic message file generation when needed

Procedure

read incoming inbox message
- input: REQUEST_ID and inbox file path (e.g., .mailbox/inbox/<id>)
- locate the file and extract frontmatter metadata: REQUEST_ID, MESSAGE_TYPE, RECEIVER_INBOX_PATH, REPLY_INBOX_PATH, CHANNEL_ID (if present)
- read the Markdown body as the payload (user prompt for NEW messages, context data for REPLY messages)
- output: parsed metadata dict and body string
scan for related messages in same channel (if applicable)
- input: CHANNEL_ID from step 1 (skip if absent)
- scan .mailbox/inbox/ for other files with matching CHANNEL_ID in frontmatter
- identify the latest pending message by timestamp or creation order
- identify any superseded older messages in the same channel
- output: list of related inbox file paths and their timestamps
read full context if multi-message channel
- input: list from step 2 (only if multiple messages in same channel)
- read the body of each related inbox message to understand the full conversation flow
- keep track of which message is newest and which are superseded
- output: map of REQUEST_ID to message context for each related message
compose reply in scratch area
- input: parsed metadata from step 1, full context from step 3 (if applicable), reply content or logic
- create a new scratch file at .mailbox/scratch/<REQUEST_ID> (reuse the same REQUEST_ID)
- write frontmatter with: REQUEST_ID (preserved), MESSAGE_TYPE: REPLY, RECEIVER_INBOX_PATH (from original), REPLY_INBOX_PATH (from original), CHANNEL_ID (preserved if present)
- write Markdown body with reply content. do not prefix with speaker labels like "assistant:" unless explicitly required
- for superseded messages in same channel, use empty body: ""
- output: completed scratch file path
deliver reply to destination inbox
- input: completed scratch file from step 4, destination path from REPLY_INBOX_PATH frontmatter
- copy (not move) the scratch file to the destination inbox path specified in REPLY_INBOX_PATH
- for superseded older messages in same channel, copy their scratch replies to their respective REPLY_INBOX_PATH values
- verify file exists at destination
- output: delivery confirmation with destination path
mark processing complete
- input: original inbox file path from step 1
- this is a logical checkpoint. your work on this message is complete. do not delete or modify the inbox file.
- output: confirmation that reply chain is closed (unless the reply itself expects a further round)

Decision Points

if MESSAGE_TYPE is NEW:

treat the body as a user prompt or request to process
compose a substantive reply (not an echo)
deliver as MESSAGE_TYPE: REPLY

if MESSAGE_TYPE is REPLY:

you are receiving an answer from another agent
read the body for context or next steps
decide if your workflow requires another round: if no, close the request; if yes, compose a follow-up REPLY using the same REQUEST_ID

if CHANNEL_ID is present:

check for other messages in .mailbox/inbox/ with the same CHANNEL_ID
if multiple pending messages share CHANNEL_ID, reply only with full content to the latest one
for superseded older messages in that channel, create minimal REPLY messages with empty body ("") and deliver each to its own REPLY_INBOX_PATH
do not ignore superseded messages; create and deliver a valid mailbox file for each

if CHANNEL_ID is absent:

treat this as a standalone message thread
no channel grouping logic applies
reply with full content and deliver once

if REPLY_INBOX_PATH is unavailable or malformed:

do not attempt delivery
log the missing path and halt; escalate to system admin for routing correction
do not invent or guess alternate paths

if inbox file cannot be read (permissions, corruption, missing):

do not proceed with reply composition
log the error and request manual intervention
do not create orphaned scratch files

if you need to read multiple inbox messages for context:

read them but reply one at a time to the correct sender and channel
refer explicitly to context from other messages when appropriate
ensure each reply stays aligned with its original sender's REQUEST_ID and CHANNEL_ID

Output Contract

scratch file format (step 4):

location: .mailbox/scratch/<REQUEST_ID>
format: Markdown with YAML frontmatter

frontmatter structure:

---
REQUEST_ID: <preserved from original>
MESSAGE_TYPE: REPLY
RECEIVER_INBOX_PATH: <from original REQUEST>
REPLY_INBOX_PATH: <from original REQUEST>
CHANNEL_ID: <preserved if present, else omitted>
---

body: Markdown text (substantive reply, or "" for superseded messages)

delivered file format (step 5):

location: destination at REPLY_INBOX_PATH from frontmatter
format: identical to scratch file (complete copy)
must be a valid Markdown file with intact YAML frontmatter
file must exist and be readable at destination after delivery

success state:

every incoming message receives a corresponding REPLY mailbox file
REQUEST_ID is preserved across all files in the request-reply chain
CHANNEL_ID is preserved if originally present
each REPLY is delivered to the correct REPLY_INBOX_PATH
scratch files are never exposed to other agents or clients; only delivered inbox copies are visible
all frontmatter fields match the original message (except MESSAGE_TYPE changes to REPLY)

Outcome Signal

you know this skill worked when:

the scratch file at .mailbox/scratch/<REQUEST_ID> is created with correct frontmatter and reply body
the scratch file is successfully copied to the destination REPLY_INBOX_PATH
the receiver can read the delivered file and confirm REQUEST_ID, MESSAGE_TYPE: REPLY, and reply content
for multi-message channels, all superseded older messages also receive valid REPLY files at their respective REPLY_INBOX_PATH values, each with minimal empty body
no errors or routing failures occur during delivery
the original inbox file remains untouched (not deleted or modified)
if a follow-up round is needed, the next incoming message arrives with the same REQUEST_ID and updated CHANNEL_ID (if applicable)
processing log (if maintained) shows clear entry and exit points for each mailbox request