Email Drafting

Email Response Drafting

This skill covers drafting email replies that sound human, thread correctly, and render properly across email clients. It is scoped to response drafting — not marketing campaigns or mass outreach.

Draft-First: The Non-Negotiable Rule

Never send an email without the user's explicit approval. The workflow:

1. Compose the draft (in markdown, in the agent's chat, or in a file) 2. Present recipients, subject, and body to the user for review 3. Save as draft to Outlook (or the user's email client) if available 4. Wait for the user to say "send," "send now," "reply now," or equivalent 5. Send only after explicit approval

If intent is ambiguous ("looks good" could mean "I approve the draft" or "I'll send it myself"), ask for one-line confirmation before sending.

Voice and Tone Matching

The cardinal rule: match the sender's register.

| Relationship | Tone | Example opener | |-------------|------|----------------| | Internal team / contractors | Short, direct, no filler | "Sent the updated file. Let me know if anything looks off." | | Existing clients (high trust) | Warm but efficient | "Quick update — the document is ready for your review." | | New contacts / cold replies | Professional, value-first | Lead with what is relevant to them, not your credentials | | Formal threads | Match their formality | If they write "Dear Steven," reply with "Dear [Name]," not "Hey!" |

Calibration signals

Read the sender's email for cues:

What to avoid

Threading: Get It Right

Broken threading looks unprofessional. Before creating a reply draft:

1. Check the subject — if it has "Re:" or "RE:", this is a reply to an existing thread 2. Find the original message — search by sender + subject keywords 3. Get the message ID — use it as the in_reply_to or reply_to parameter 4. Create a threaded reply — not a standalone new message

If the original message cannot be found, tell the user rather than silently creating a standalone draft that will break the thread in the recipient's inbox.

REST API: Use POST /me/messages/{id}/createReply to maintain threading. This preserves conversation ID and In-Reply-To headers.

MCP: reply_to_email handles threading automatically.

Structure: One Ask Per Email

Every email should have exactly one clear action item. If you need multiple things, either:

Structure template for action-needed replies:

[1-2 sentence context/update]
[The ask — what you need from them, by when]
[Optional: supporting detail they might need to act]

Structure template for informational replies:

[The news — what happened or what's ready]
[Optional: what they should do next, or "no action needed"]

Formatting That Survives Email Clients

Email rendering is a minefield. Markdown that looks perfect in a text editor can break in Outlook, Gmail, or Apple Mail.

Gotchas

| Issue | What breaks | Fix | |-------|------------|-----| | Cuddled lists | No blank line before first - item | Always add a blank line before the first list item | | Raw markdown in HTML | bold renders as literal asterisks in HTML email | Convert markdown to HTML before sending | | Missing plain-text body | HTML-only emails get flagged by spam filters | Always include both HTML and plain-text versions | | Signature placement | Signature appears before the quoted thread | Put signature after reply body, before the quoted thread | | Long URLs | URLs wrap mid-word and break clickability | Use hyperlink text click here in markdown; convert to in HTML | | Tables | Many email clients don't render markdown tables | Use HTML

---
to: recipient@example.com
subject: Re: Project update
in_reply_to: 
Body of the email in markdown.
The MCP or send script converts this to HTML + plain text automatically.