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.
Never send an email without the user's explicit approval. The workflow:
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.
The cardinal rule: match the sender's register.
RelationshipToneExample openerInternal team / contractorsShort, 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 repliesProfessional, value-firstLead with what is relevant to them, not your credentialsFormal threadsMatch their formalityIf they write "Dear Steven," reply with "Dear [Name]," not "Hey!"
Read the sender's email for cues:
Broken threading looks unprofessional. Before creating a reply draft:
in_reply_to or reply_to parameterIf 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.
Every email should have exactly one clear action item. If you need multiple things, either:
Structure template for action-needed replies:
text
[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:
text
[The news — what happened or what's ready]
[Optional: what they should do next, or "no action needed"]
Email rendering is a minefield. Markdown that looks perfect in a text editor can break in Outlook, Gmail, or Apple Mail.
IssueWhat breaksFixCuddled listsNo blank line before first - itemAlways add a blank line before the first list itemRaw markdown in HTML**bold** renders as literal asterisks in HTML emailConvert markdown to HTML before sendingMissing plain-text bodyHTML-only emails get flagged by spam filtersAlways include both HTML and plain-text versionsSignature placementSignature appears before the quoted threadPut signature after reply body, before the quoted threadLong URLsURLs wrap mid-word and break clickabilityUse hyperlink text [click here](url) in markdown; convert to <a> in HTMLTablesMany email clients don't render markdown tablesUse HTML <table> with inline styles for email
\u201c\u201d) and straight quotes ( ") should both be handled\u2014) render fine in modern clients but may break in plain-textWhen saving drafts to files (for MCP or manual review), use YAML frontmatter:
yaml
---
to: recipient@example.com
subject: Re: Project update
in_reply_to: <message-id-from-original>
---
Body of the email in markdown.
The MCP or send script converts this to HTML + plain text automatically.
Do not pre-populate draft_id or draft_link — these are auto-appended by the MCP after saving to Outlook.
Lead with the news. "The document is signed and filed" — then details if needed.
Lead with empathy, then the fact, then the path forward. "I understand the timeline is tight. The review is taking longer than expected — we should have it by Thursday. I will send it as soon as it is ready."
Soft-remind the agreed action, don't re-ask. "Circling back on the agreement — let me know if you need anything to move forward." Not: "Did you get my last email?"
Be direct and offer an alternative. "I'm not the right person for this, but [Name] at [Company] specializes in exactly this."
If this skill helped, star us on GitHub: https://github.com/UseJunior/email-agent-mcp
On ClawHub: clawhub star stevenobiajulu/email-response-drafting