html-email
Send-ready single-file email
git clone --depth 1 https://github.com/asgeirtj/system_prompts_leaks /tmp/html-email && cp -r /tmp/html-email/Anthropic/claude-design/skills/html-email ~/.claude/skills/html-emailSKILL.md
# HTML email Design an HTML email as ONE self-contained .html file that survives real email clients. Email rendering is not browser rendering — Gmail, Outlook, and Apple Mail each strip or mangle different things, and the rules below are what reliably survives all three. When a rule here conflicts with normal web-design instincts, the rule wins. Layout and styling: - Structure with nested `<table role="presentation" cellpadding="0" cellspacing="0" border="0">` — no flexbox, no grid, no floats, no position. One centered wrapper table, max-width 600px, single-column flow (stacked rows beat side-by-side columns). - Inline EVERY style on the element it styles. A `<style>` block in `<head>` may additionally carry only what can't inline (media queries, dark-mode tweaks) — several clients drop it entirely, so the email must read correctly from inline styles alone. - No JavaScript anywhere (universally stripped). No external stylesheets. No web fonts — use email-safe stacks (Arial, Helvetica, Georgia, Verdana, Tahoma, 'Courier New') with generic fallbacks. - Build the visual design out of colored table cells, borders, spacer cells, and type — not images. There is nowhere to host project images from here: a referenced project file will not exist for recipients. If imagery is essential, leave a clearly-marked placeholder cell with alt text and tell the user to swap in a hosted https URL before sending. - Buttons are "bulletproof": a padded `<td>` with bgcolor and inline border-radius, the `<a>` filling it with display:block and inline color — never an image, never a styled `<button>`. Client quirks that matter: - Outlook (Word engine): give every table/cell explicit widths; set line-height with mso-line-height-rule:exactly; wrap Outlook-only fixes in `<!--[if mso]> … <![endif]-->` conditionals. - Gmail clips messages beyond ~100KB of HTML — stay well under. - Add `<meta name="color-scheme" content="light dark">` and pick colors that survive dark-mode inversion (avoid pure `#000/#fff` backgrounds; test text on mid-tone fills). Deliverability and accessibility: - First element in `<body>`: a hidden preheader span (~85 chars) that previews next to the subject line. - alt text on any image, lang on `<html>`, real `<a href>` links (no dead # anchors), and a footer with a plausible unsubscribe line and postal address for anything marketing-shaped. Show the design at 600px; mention in your reply that the file is send-ready HTML the user can drop into their email tool.
Deep research harness — fan-out web searches, fetch sources, adversarially verify claims, synthesize a cited report.
Author or improve the run-<unit> skill - a per-project skill that tells agents how to build, launch, and drive this project's app. Use when the user asks to set up the project, get it running, write run instructions, or verify build/run steps work from a clean environment.
Runtime capabilities a published Artifact page can be granted — behavior static HTML cannot provide on its own, such as the page reading live or connected data, remembering what people do on it (a poll, a sign-up sheet, a checklist, a document edited in place — it saves new versions of itself), keeping state shared across viewers, knowing who is viewing, asking Claude a question of its own, storing files people add, or handing the viewer a file to save. Serves this user's live capability roster and the typed call definitions. Load it whenever the user asks for an artifact needing any such runtime behavior.
Design guidance and fundamentals for Artifacts.
Diagramming know-how for Artifacts - when a picture earns its place, how to draw one that shows the real mechanism, and the inline-SVG mechanics that keep it legible in both themes.
Research and plan a large-scale change, then execute it in parallel across 5–30 isolated worktree agents that each open a PR.
Automates your Chrome browser to interact with web pages - clicking elements, filling forms, capturing screenshots, reading console logs, and navigating sites. Opens pages in new tabs within your existing Chrome session. Requires site-level permissions before executing (configured in the extension).
Review the current diff, or a PR number/branch/path target, for correctness bugs and reuse/simplification/efficiency cleanups at the given effort level (low/medium: fewer, high-confidence findings; high→max: broader coverage, may include uncertain findings; ultra: deep multi-agent review in the cloud); with no level given, it reuses the level you typed last. Pass --comment to post findings as inline PR comments, or --fix to apply the findings to the working tree after the review. For ultra on a GitHub.com PR target, --post asks to post the finished review’s findings to the PR as a single comment from the user’s GitHub account (not a review; the launch dialog still confirms in interactive sessions, while non-interactive mode posts on the flag alone) and --no-post hides that option.