feat(skills): add optional mail auto-draft skill

[jozrftamson]

Summary

• add an optional email skill for Himalaya-based inbound auto-reply workflows
• document self-reply protection, Reply-To-aware recipient selection, and Gmail append-failure behavior
• include a production checklist reference for safe deployment

Why this matters

Many users want lightweight email automation on their own mailbox without introducing a hosted SaaS inbox or building a full custom integration from scratch. This skill gives Hermes a practical path for handling simple inbound email workflows with tools many Linux users already have: Himalaya, Python, and systemd.

It also emphasizes safety patterns that are easy to get wrong in email automation:

• self-reply loop prevention via own_addresses
• Reply-To-aware recipient selection
• safe handling of Gmail SMTP-success / IMAP-append-failure edge cases
• conservative production defaults for auto-send

Example workflow

A user wants Hermes to monitor a Gmail inbox for new inbound messages and automatically respond to simple categories such as:

• information requests
• basic appointment requests
• simple acknowledgement emails

With this skill, Hermes can guide the setup of:

1. Himalaya IMAP/SMTP account configuration
2. a local Python-based inbound processing script
3. safe config defaults for whitelist-only auto-send
4. a systemd user timer for continuous background processing
5. checks to avoid replying to the user’s own outbound mail

Why optional instead of bundled

This is intentionally proposed under optional-skills/email rather than bundled default skills because it is useful but not universal.

It requires:

• a locally configured mailbox
• Himalaya CLI
• Python dependencies
• machine-specific deployment decisions
• provider-specific operational knowledge such as Gmail behavior

That makes it a strong fit for an official optional skill: valuable, practical, and reusable, but not something every Hermes installation should enable or surface by default.

Testing

• skill content written in fork under optional-skills/email/mail-auto-draft/
• structure matches existing optional skill layout
• references file included for production safety checklist

[eve-coda]

Hey @jozrftamson — saw this PR while searching for prior art on email draft workflows. I just opened #5717, which adds an EMAIL_SUPPRESS_OUTBOUND env var to the built-in email adapter that unconditionally drops outbound SMTP from EmailAdapter.send() / send_image() / send_document() regardless of what the agent emits.

The two PRs operate at different layers and seem complementary rather than competing:

• This PR (feat(skills): add optional mail auto-draft skill #3471) — a higher-level workflow recipe: Himalaya CLI + Python + systemd for end-to-end inbound auto-draft / auto-reply, with safety patterns (self-reply loop prevention, Reply-To handling, etc.) layered on top.
• feat(gateway): add EMAIL_SUPPRESS_OUTBOUND kill switch for draft-only mailboxes #5717 — a low-level adapter primitive: a hard kill switch in gateway/platforms/email.py that stops the built-in adapter from sending anything via SMTP, enforced at the adapter rather than via prompt instructions.

A user adopting your skill could optionally also set EMAIL_SUPPRESS_OUTBOUND=true on the built-in email adapter as a defense-in-depth backstop — useful if a parallel gateway config is also enabled and you want a single switch that guarantees nothing leaks via the gateway/platforms/email.py path while your Himalaya-based flow handles the actual approved outbound.

Just flagging in case it's useful context for reviewers looking at either PR. Happy to coordinate if there's any overlap I'm not seeing.