`, `banner-eyebrow`, `banner-title`, `banner-subtitle`, `banner-date`, and the `.content` body. The `<style>` block is copy-pasted verbatim — don't redesign it per report. - **`.content` is markdown output, not custom markup.** Render the report body as plain `h2`/`h3`/`p`/`ul`/`ol`/`table`/`blockquote`/`hr`/`img` — the CSS already styles all of them. Don't hand-build stat cards or custom divs inside `.content`; the template doesn't have classes for them. - **`.banner-eyebrow`** is the product/agent name generating the report; swap it for the automation's own name. - **Footer is a one-line disclaimer or attribution**, not the fleet footer from Template A — this document stands alone (opened directly, attached, or hosted), it doesn't need the "Browse more →" link. --- ## Putting them together **Script/job reports (Template B):** 1. Generate the report as its own `.html` file using **Template B**, named for what it is (e.g. `Weekly_Security_Briefing.html`), saved next to the automation's other outputs. 2. Send the notification email using **Template A** as the body — one or two sentences on what's in the report, a CTA link if the report is hosted somewhere, or send the report file as an email attachment. 3. Keep the subject line and label conventions from Template A even when the body is otherwise custom — that's what makes an inbox filter and a fleet-wide tag keep working. **Workflow-tool digests (Template C):** the agent/job emits Markdown → a shared render step turns it into Template C's light-card HTML → that HTML is optionally archived somewhere durable → the sender delivers it as **both** the inline HTML body and a `.html` attachment, picking up Template A's footer automatically via the shared footer helper. Don't build a separate short Template A body for these — inline the full digest, unlike the Template B report flow. Regardless of which body template: subject line and label conventions come from Template A, and the footer is always appended by a shared helper — it's not something you hand-write per template. --- ## Sending it These templates only produce HTML and text — something still has to call an email API. The templates are deliberately transport-agnostic, so any of these works: | Mechanism | Use when | Notes | |---|---|---| | **A transactional email API** (Resend, Postmark, SendGrid, SES…) | Any new automation email | The normal choice. All of them take an HTML body, a plain-text alternative, attachments, and a tag/label for filtering — which is exactly what these templates emit. Verify a sending domain first, or your mail lands in spam. | | **A mail MCP server** | Searching, labeling, or filtering existing mail | Most read-only mail integrations can't send. Check before you wire one in as a delivery path. | | **Raw SMTP** | A one-off script, or a host that already has a relay | Fine for low volume. You give up delivery tracking, bounce handling, and per-message tagging. | > [!IMPORTANT] > **Write one sender and reuse it.** The single biggest source of drift in an automation fleet > is every job growing its own send function — each with slightly different footer handling, > retry behavior, and API-key resolution. Put one small module behind the templates: > it takes `(subject, html, text, attachments, tag)`, appends the shared footer, and is the > only thing in the codebase that holds the API key. **Key resolution is the trap.** A sender that works interactively fails under a scheduler, because the scheduled task runs as a different user and never sees your shell environment. Decide explicitly where the key comes from — process env, a secrets file, the scheduler's own secret store — and document it next to the sender, not in your head.

# HTML Email Templates > Three reusable HTML email templates for automated systems, built to survive the email clients that strip your CSS — a plain inline-styled notification/alert, a dark banner report wrapper, and an inline light-card digest — plus the subject-line, label and shared-footer conventions that keep a fleet of automated emails consistent and filterable. Transport-agnostic: the templates emit HTML and plain text, so any transactional email API (Resend, Postmark, SendGrid, SES) or SMTP relay can send them. Use whenever building or sending an automated email, alert, notification, digest, status report, or a generated report that gets emailed or attached. - Skill: `ai-automation-tools/html-email-templates` (Agent Skill) - Install (CLI): `npx skillmds@latest add ai-automation-tools/html-email-templates` - Raw SKILL.md: https://api.skillmd.com/api/skills/ai-automation-tools/html-email-templates/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Web & Frontend - Author: ai-automation-tools (https://skillmd.com/u/ai-automation-tools) - Updated: 2026-09-22 - Page: https://skillmd.com/skills/ai-automation-tools/html-email-templates --- # Email Template Three templates, used together or alone. Pick based on what the email *is* and which system generates it: | Email is... | Use | Delivery | |---|---|---| | A notification, alert, or short status update | **A — Notification** | inline HTML, the email body itself | | A generated report (analysis, briefing, summary) from a script or job | **B — Report** | standalone `.html` file, attach it or link it — don't paste it as the email body | | A markdown digest generated by a workflow tool (weekly/daily briefings, newsletters) | **C — Inline digest** | rendered to light-card HTML and inlined directly as the body (safe — inline styles only, no CSS vars) | A report email is usually **both A and B (or C)**: template A's footer is appended to every send regardless of which body template produced the content — that's a shared footer helper's job, not a per-template choice. For script/job artifacts, template B stays an attachment/link per the note below. For workflow-tool digests, the fleet can inline template C's *full* HTML as the body **and** still attach the archived `.html` file — both, not either/or. > **Why not inline Template B into the email body?** Template B relies on CSS custom properties (`var(--x)`), `background-clip: text`, and `backdrop-filter` — Gmail and Outlook strip or mangle all three. It renders correctly in a browser or PDF, not in an email client's DOM. Keep it as an attachment or a hosted link. Template C avoids this problem entirely by using only inline `style="..."` attributes — that's why it's safe to inline. --- ## Template A — Notification / alert Plain inline styles only, no `

{report_body_html — h2/h3/p/ul/ol/table/blockquote/hr/img, exactly what a markdown-to-HTML render of the report produces}

``` Rules: - **Only four things change per report:** ``, `banner-eyebrow`, `banner-title`, `banner-subtitle`, `banner-date`, and the `.content` body. The `<style>` block is copy-pasted verbatim — don't redesign it per report. - **`.content` is markdown output, not custom markup.** Render the report body as plain `h2`/`h3`/`p`/`ul`/`ol`/`table`/`blockquote`/`hr`/`img` — the CSS already styles all of them. Don't hand-build stat cards or custom divs inside `.content`; the template doesn't have classes for them. - **`.banner-eyebrow`** is the product/agent name generating the report; swap it for the automation's own name. - **Footer is a one-line disclaimer or attribution**, not the fleet footer from Template A — this document stands alone (opened directly, attached, or hosted), it doesn't need the "Browse more →" link. --- ## Putting them together **Script/job reports (Template B):** 1. Generate the report as its own `.html` file using **Template B**, named for what it is (e.g. `Weekly_Security_Briefing.html`), saved next to the automation's other outputs. 2. Send the notification email using **Template A** as the body — one or two sentences on what's in the report, a CTA link if the report is hosted somewhere, or send the report file as an email attachment. 3. Keep the subject line and label conventions from Template A even when the body is otherwise custom — that's what makes an inbox filter and a fleet-wide tag keep working. **Workflow-tool digests (Template C):** the agent/job emits Markdown → a shared render step turns it into Template C's light-card HTML → that HTML is optionally archived somewhere durable → the sender delivers it as **both** the inline HTML body and a `.html` attachment, picking up Template A's footer automatically via the shared footer helper. Don't build a separate short Template A body for these — inline the full digest, unlike the Template B report flow. Regardless of which body template: subject line and label conventions come from Template A, and the footer is always appended by a shared helper — it's not something you hand-write per template. --- ## Sending it These templates only produce HTML and text — something still has to call an email API. The templates are deliberately transport-agnostic, so any of these works: | Mechanism | Use when | Notes | |---|---|---| | **A transactional email API** (Resend, Postmark, SendGrid, SES…) | Any new automation email | The normal choice. All of them take an HTML body, a plain-text alternative, attachments, and a tag/label for filtering — which is exactly what these templates emit. Verify a sending domain first, or your mail lands in spam. | | **A mail MCP server** | Searching, labeling, or filtering existing mail | Most read-only mail integrations can't send. Check before you wire one in as a delivery path. | | **Raw SMTP** | A one-off script, or a host that already has a relay | Fine for low volume. You give up delivery tracking, bounce handling, and per-message tagging. | > [!IMPORTANT] > **Write one sender and reuse it.** The single biggest source of drift in an automation fleet > is every job growing its own send function — each with slightly different footer handling, > retry behavior, and API-key resolution. Put one small module behind the templates: > it takes `(subject, html, text, attachments, tag)`, appends the shared footer, and is the > only thing in the codebase that holds the API key. **Key resolution is the trap.** A sender that works interactively fails under a scheduler, because the scheduled task runs as a different user and never sees your shell environment. Decide explicitly where the key comes from — process env, a secrets file, the scheduler's own secret store — and document it next to the sender, not in your head.