[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6QVDXT1BYYPJR8AY4B5HYY5":3,"skill-same:01M6QVDXT1BYYPJR8AY4B5HYY5":83},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":34,"publishedAt":55,"linkOnly":56,"markdownContent":57,"markdownBody":58,"frontMatter":59,"refName":61,"commitSha":62,"skillDirectory":63,"forksCount":64,"repositoryHtmlUrl":65,"repositoryHomepageUrl":6,"ownerHtmlUrl":66,"ownerBlogUrl":67,"ownerDescription":6,"updatedAt":68,"install":69,"resources":82},"01M6QVDXT1BYYPJR8AY4B5HYY5","html-email-templates",null,"Design, write, review, or debug HTML email templates that must survive Outlook, Gmail, Apple Mail, dark mode, images-off, and mobile constraints. Use when creating transactional emails, lifecycle emails, newsletters, bulletproof buttons, hybrid-fluid table layouts, VML Outlook fallbacks, inlined CSS, plain-text alternatives, preheaders, or client-specific rendering fixes.","maltehedderich\u002Fmaster-class-agents","maltehedderich","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F12952192?v=4","01M6QVCWP46HX90VYH1107TWGD","Malte Hedderich","01M6QVCWTNYVG7SQD18WCYVGAF",6,"MIT","https:\u002F\u002Fgithub.com\u002Fmaltehedderich\u002Fmaster-class-agents\u002Fblob\u002Fmain\u002Fskills\u002Fhtml-email-templates\u002FSKILL.md",[18,23,26,29],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000005","邮件与沟通","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000009","前端开发",{"categoryNo":27,"categoryName":28,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":30,"categoryName":31,"taxonomyType":32,"taxonomyTypeDesc":33},"01JBSEEDCAT000000000000032","设计师","PROFESSION","适用职业",[35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54],"html email templates","email","templates","html","goal","mode","transactional","plain-text","rendering","apple","mail","mobile","images","design","write","text","ESP","css","review","gmail","2026-11-10 10:12:30",false,"---\nname: html-email-templates\ndescription: \"Design, write, review, or debug HTML email templates that must survive Outlook, Gmail, Apple Mail, dark mode, images-off, and mobile constraints. Use when creating transactional emails, lifecycle emails, newsletters, bulletproof buttons, hybrid-fluid table layouts, VML Outlook fallbacks, inlined CSS, plain-text alternatives, preheaders, or client-specific rendering fixes.\"\nargument-hint: \"Goal, email type, copy or draft, brand constraints, ESP\u002Fbuild constraints, and target client matrix\"\n---\n\n# HTML Email Templates\n\n## What This Skill Does\n\nBuild or review HTML email the way email clients require, not the way browsers prefer.\n\nThis skill treats email as a constrained rendering target with one controlling rule: design for the worst renderer you must support, then progressively enhance for the rest. In practice that usually means Outlook for Windows decides the floor, while Gmail, Apple Mail, Outlook.com, and mobile clients get the enhancements they can support.\n\nUse this skill to:\n\n- Create a new production-ready HTML email template.\n- Adapt a web design into email-safe markup.\n- Review or debug an existing template that breaks in Outlook, Gmail, dark mode, or images-off states.\n- Produce bulletproof components such as buttons, hero sections, background-image blocks, and hybrid multi-column layouts.\n- Return both the HTML version and the supporting delivery artifacts that email work actually needs, such as preheader text, plain-text copy, fallback notes, and a testing checklist.\n\nThis skill is for HTML email craft. It is not for landing pages, regular web UI, or browser-only HTML.\n\n## When to Use\n\n- The request involves HTML email, MJML-to-HTML review, ESP template markup, or responsive email layout.\n- A design must render acceptably in Outlook for Windows, Gmail, Apple Mail, Outlook.com, or mobile mail clients.\n- The user needs table-based layout, inline CSS, dark-mode handling, VML, or image blocking fallbacks.\n- The user asks for a transactional email, lifecycle email, marketing email, newsletter, or email component.\n- The user has a broken template and needs client-specific diagnosis instead of generic HTML advice.\n\nDo not use this skill for:\n\n- Browser-only HTML where flexbox, grid, and normal CSS support are acceptable.\n- Deliverability strategy beyond the template itself.\n- Copywriting from scratch when the user has provided no message content at all.\n\n## Inputs To Gather\n\nAsk for whatever is missing before building or fixing the template.\n\n- `goal` - `draft`, `review`, `debug`, or `adapt`.\n- `email_type` - `transactional`, `lifecycle`, `marketing`, `newsletter`, or another specific category.\n- `copy` - subject, preheader, headline, body copy, CTA text, footer copy, legal copy, and links.\n- `brand_constraints` - colors, logo rules, typography limits, tone, spacing, imagery, and whether dark mode has branded requirements.\n- `target_clients` - explicit client matrix if known.\n- `authoring_constraints` - raw HTML, MJML source, ESP partials, template language, merge tags, or build pipeline requirements.\n- `asset_constraints` - image formats, image hosting, SVG allowance, tracking parameters, and background image requirements.\n- `size_constraints` - strict payload budget or clipping concerns.\n\nIf `target_clients` is missing, default to a conservative matrix:\n\n- Gmail web\n- Gmail mobile app\n- Apple Mail\n- iOS Mail\n- Outlook for Windows\n- Outlook.com\n- one Android mail client\n\nIf the request is to review or debug existing email HTML, ask for the exact HTML and the failing clients. If the request is net-new and the copy is incomplete, ask whether placeholders are acceptable before inventing copy.\n\n## Non-Negotiable Constraints\n\nTreat these as defaults unless the user explicitly narrows the support target.\n\n1. Table-based layout is the foundation. Do not build the core layout with divs, flexbox, grid, float, or position-based tricks.\n2. Use a hybrid-fluid approach: fixed widths for Outlook compatibility, percentage widths and max-width behavior elsewhere.\n3. Inline CSS is the default. Keep a style block only for rules that cannot be inlined, such as media queries, hover states, or dark-mode overrides.\n4. Outlook-specific fixes belong in conditional comments or VML when needed.\n5. Treat dark mode, images-off, and mobile as first-class targets.\n6. Keep critical content as real HTML text, not text baked into images.\n7. Watch Gmail clipping. Large decorative markup is a bug, not a style choice.\n8. If a CSS feature is not clearly safe for the target matrix, avoid it or make it progressive enhancement only.\n\n## Procedure\n\nFollow the steps in order. Do not skip the renderer-floor decision.\n\n### Step 1 - Establish the job and the renderer floor\n\nDetermine:\n\n- whether the task is net-new, review, debug, or adaptation\n- the email category and sending context\n- the exact clients that must work\n- whether the output must be raw final HTML or source for an email build system\n\nName the worst renderer that must remain fully functional. Usually this is Outlook for Windows. From that point on, every layout choice must remain valid there.\n\n### Step 2 - Define the content hierarchy before touching markup\n\nMap the email into a small number of modules:\n\n- preheader\n- logo or brand header\n- headline\n- supporting copy\n- primary CTA\n- optional secondary modules\n- footer and legal content\n\nReduce the message to one primary action whenever possible. Transactional email should usually have one CTA and minimal decorative structure. If the hierarchy is muddy, fix the content structure before coding.\n\n### Step 3 - Pick the safest layout pattern\n\nChoose the layout from the support constraints, not from aesthetics.\n\n- Single-column email: default for transactional and lifecycle messages.\n- Hybrid two-column or card layout: use only when the content truly needs it.\n- Background-image hero: only when the design requires it and you can provide an Outlook fallback.\n\nWhen multi-column behavior is required, use the fluid-hybrid pattern so the layout still degrades acceptably when media queries fail.\n\n### Step 4 - Build the structural scaffold\n\nUse nested presentation tables with explicit spacing controls.\n\n- Use `table`, `tr`, and `td` as layout primitives.\n- Set `role=\"presentation\"` on layout tables.\n- Zero out `cellpadding`, `cellspacing`, and `border`.\n- Keep widths explicit where Outlook needs them.\n- Use predictable spacing with padding on table cells instead of margin-dependent layout.\n\nIf authoring in a readable source format first, plan for a real inlining step before final delivery.\n\n### Step 5 - Implement bulletproof components\n\nBuild every visible component with fallbacks in mind.\n\n- Buttons: make the CTA readable and clickable without relying on background-only styling.\n- Images: always include width, alt text, and an acceptable images-off experience.\n- Typography: use safe font fallbacks and readable default sizes.\n- Dividers, cards, and feature rows: keep them table-based.\n- Background images or rounded CTA treatments: add VML only when the visual requirement justifies the markup weight.\n\nPrefer a plain component that works everywhere over a clever component that fails in one major client.\n\n### Step 6 - Add progressive enhancement carefully\n\nEnhancement is optional. Function is mandatory.\n\n- Add media queries only after the base layout already works.\n- Add dark-mode rules only after the light version is structurally sound.\n- Add hover states or web-font improvements only as bonuses.\n- Use Outlook conditionals for Outlook problems, not for every stylistic preference.\n\nIf a feature cannot degrade cleanly, remove it.\n\n### Step 7 - Design for dark mode and images-off\n\nReview the template in hostile viewing conditions.\n\n- Ensure text still has contrast if colors invert.\n- Avoid relying on pure black and pure white for main surfaces when a softer equivalent is safer.\n- Make logos and icons survive dark backgrounds or inversion.\n- Ensure the CTA remains understandable when images are blocked.\n- Keep meaningful copy out of hero images.\n\nDark mode parity is not required. Legibility and brand survival are required.\n\n### Step 8 - Add accessibility and fallback content\n\nEmail accessibility is part of the implementation, not a cleanup pass.\n\n- Set the document language when you control the outer HTML.\n- Include a descriptive title when relevant.\n- Use meaningful alt text, and empty alt text for decorative images.\n- Keep reading order aligned with the visual hierarchy.\n- Use live text for all essential message content.\n- Include a preheader that complements the subject instead of repeating it.\n- Provide a plain-text version when the send system expects one.\n\n### Step 9 - Trim weight and remove fragile markup\n\nBefore returning the template, reduce unnecessary size and risk.\n\n- Remove unused classes, comments, redundant wrappers, and decorative cruft.\n- Watch total size with Gmail clipping in mind.\n- Do not keep duplicated structures unless a client-specific fallback genuinely requires them.\n- Prefer simple nested tables over sprawling compatibility hacks copied without a reason.\n\n### Step 10 - Test against the client matrix\n\nDo not declare the template ready without a test plan.\n\nAt minimum, verify:\n\n- the required client matrix\n- mobile rendering\n- dark mode where relevant\n- images blocked\n- click targets and link destinations\n- footer and unsubscribe or legal content where applicable\n\nIf the user is asking for code only and no preview tooling is available, return the template with explicit testing notes and the highest-risk clients called out.\n\n## Branching Logic\n\n- **Transactional or lifecycle email.** Default to a narrow single-column layout, one main CTA, low markup weight, and maximum resilience.\n- **Marketing or newsletter email.** Allow more modules, but police size aggressively and keep decorative sections subordinate to render safety.\n- **Adapting a web design.** Rebuild the layout in email-safe structures. Do not transliterate div-based browser markup into email and hope.\n- **Existing template fails in Outlook.** Strip the issue back to tables, widths, padding, conditional comments, and VML needs before changing visual design.\n- **Existing template fails only in dark mode.** Check inversion behavior, transparent assets, and hardcoded colors before touching layout.\n- **Background image is requested.** Provide an Outlook-safe fallback or explicitly recommend dropping the background image.\n- **Multi-column layout is requested.** Use fluid-hybrid stacking rather than media-query-only stacking when older Gmail behavior matters.\n- **Unknown CSS feature seems useful.** Treat it as unsupported until verified against the target matrix.\n- **The HTML is already too large.** Cut modules, wrappers, comments, and decorative code before adding new fallback layers.\n\n## Output Format\n\nReturn the result in the form that matches the task.\n\nFor `draft` or `adapt`:\n\n1. The email HTML, or the corrected section when only part of the template was requested.\n2. Any required supporting notes, such as where CSS must be inlined or where ESP merge tags belong.\n3. Preheader text and a plain-text fallback when the request implies a send-ready email.\n4. A short compatibility note naming the important fallbacks and the highest-risk clients.\n\nFor `review` or `debug`:\n\n1. The concrete rendering problems found.\n2. The corrected HTML or corrected snippets.\n3. The client-specific reasoning behind the fix.\n4. Remaining risks or tests that still need confirmation.\n\nIf required inputs are missing, stop and ask only for the minimum missing items.\n\n## Quality Checks\n\nThe work is ready only when all of the following are true:\n\n1. The layout is table-based and does not depend on unsupported CSS for structure.\n2. Outlook for Windows gets a functional version of the email.\n3. The main CTA is obvious, tappable, and understandable without images.\n4. The email remains readable on mobile.\n5. Dark mode does not destroy legibility or make brand assets disappear.\n6. Images have appropriate alt handling.\n7. Critical content is real text.\n8. The markup is not bloated enough to make Gmail clipping likely without reason.\n9. The template includes the content users expect in an email, including preheader and footer needs.\n10. The response names any assumptions, unsupported requests, or unverified client behavior.\n\n## Failure Modes To Avoid\n\n- Treating email like normal frontend work.\n- Starting from a browser layout and only later thinking about Outlook.\n- Using flexbox or grid for the structural layout.\n- Returning beautiful code that collapses in one mainstream client.\n- Ignoring dark mode until the end.\n- Hiding important text in images.\n- Shipping markup so large that Gmail clipping becomes likely.\n- Adding compatibility hacks that you cannot explain.\n- Claiming a template is ready without naming the test matrix.\n\n## Default Stance\n\nBe conservative, explicit, and honest about compatibility. The plain version that works in Outlook is better than the ambitious version that breaks there. Build from table structure, inline styles, and clear fallbacks first. Treat modern CSS as a bonus layer, not as the foundation.\n\nAssume the final deliverable is hand-authored HTML unless the user explicitly asks for MJML or another authoring system. Support both transactional and marketing email, but default toward the stricter transactional standard when tradeoffs are unclear.","# HTML Email Templates\n\n## What This Skill Does\n\nBuild or review HTML email the way email clients require, not the way browsers prefer.\n\nThis skill treats email as a constrained rendering target with one controlling rule: design for the worst renderer you must support, then progressively enhance for the rest. In practice that usually means Outlook for Windows decides the floor, while Gmail, Apple Mail, Outlook.com, and mobile clients get the enhancements they can support.\n\nUse this skill to:\n\n- Create a new production-ready HTML email template.\n- Adapt a web design into email-safe markup.\n- Review or debug an existing template that breaks in Outlook, Gmail, dark mode, or images-off states.\n- Produce bulletproof components such as buttons, hero sections, background-image blocks, and hybrid multi-column layouts.\n- Return both the HTML version and the supporting delivery artifacts that email work actually needs, such as preheader text, plain-text copy, fallback notes, and a testing checklist.\n\nThis skill is for HTML email craft. It is not for landing pages, regular web UI, or browser-only HTML.\n\n## When to Use\n\n- The request involves HTML email, MJML-to-HTML review, ESP template markup, or responsive email layout.\n- A design must render acceptably in Outlook for Windows, Gmail, Apple Mail, Outlook.com, or mobile mail clients.\n- The user needs table-based layout, inline CSS, dark-mode handling, VML, or image blocking fallbacks.\n- The user asks for a transactional email, lifecycle email, marketing email, newsletter, or email component.\n- The user has a broken template and needs client-specific diagnosis instead of generic HTML advice.\n\nDo not use this skill for:\n\n- Browser-only HTML where flexbox, grid, and normal CSS support are acceptable.\n- Deliverability strategy beyond the template itself.\n- Copywriting from scratch when the user has provided no message content at all.\n\n## Inputs To Gather\n\nAsk for whatever is missing before building or fixing the template.\n\n- `goal` - `draft`, `review`, `debug`, or `adapt`.\n- `email_type` - `transactional`, `lifecycle`, `marketing`, `newsletter`, or another specific category.\n- `copy` - subject, preheader, headline, body copy, CTA text, footer copy, legal copy, and links.\n- `brand_constraints` - colors, logo rules, typography limits, tone, spacing, imagery, and whether dark mode has branded requirements.\n- `target_clients` - explicit client matrix if known.\n- `authoring_constraints` - raw HTML, MJML source, ESP partials, template language, merge tags, or build pipeline requirements.\n- `asset_constraints` - image formats, image hosting, SVG allowance, tracking parameters, and background image requirements.\n- `size_constraints` - strict payload budget or clipping concerns.\n\nIf `target_clients` is missing, default to a conservative matrix:\n\n- Gmail web\n- Gmail mobile app\n- Apple Mail\n- iOS Mail\n- Outlook for Windows\n- Outlook.com\n- one Android mail client\n\nIf the request is to review or debug existing email HTML, ask for the exact HTML and the failing clients. If the request is net-new and the copy is incomplete, ask whether placeholders are acceptable before inventing copy.\n\n## Non-Negotiable Constraints\n\nTreat these as defaults unless the user explicitly narrows the support target.\n\n1. Table-based layout is the foundation. Do not build the core layout with divs, flexbox, grid, float, or position-based tricks.\n2. Use a hybrid-fluid approach: fixed widths for Outlook compatibility, percentage widths and max-width behavior elsewhere.\n3. Inline CSS is the default. Keep a style block only for rules that cannot be inlined, such as media queries, hover states, or dark-mode overrides.\n4. Outlook-specific fixes belong in conditional comments or VML when needed.\n5. Treat dark mode, images-off, and mobile as first-class targets.\n6. Keep critical content as real HTML text, not text baked into images.\n7. Watch Gmail clipping. Large decorative markup is a bug, not a style choice.\n8. If a CSS feature is not clearly safe for the target matrix, avoid it or make it progressive enhancement only.\n\n## Procedure\n\nFollow the steps in order. Do not skip the renderer-floor decision.\n\n### Step 1 - Establish the job and the renderer floor\n\nDetermine:\n\n- whether the task is net-new, review, debug, or adaptation\n- the email category and sending context\n- the exact clients that must work\n- whether the output must be raw final HTML or source for an email build system\n\nName the worst renderer that must remain fully functional. Usually this is Outlook for Windows. From that point on, every layout choice must remain valid there.\n\n### Step 2 - Define the content hierarchy before touching markup\n\nMap the email into a small number of modules:\n\n- preheader\n- logo or brand header\n- headline\n- supporting copy\n- primary CTA\n- optional secondary modules\n- footer and legal content\n\nReduce the message to one primary action whenever possible. Transactional email should usually have one CTA and minimal decorative structure. If the hierarchy is muddy, fix the content structure before coding.\n\n### Step 3 - Pick the safest layout pattern\n\nChoose the layout from the support constraints, not from aesthetics.\n\n- Single-column email: default for transactional and lifecycle messages.\n- Hybrid two-column or card layout: use only when the content truly needs it.\n- Background-image hero: only when the design requires it and you can provide an Outlook fallback.\n\nWhen multi-column behavior is required, use the fluid-hybrid pattern so the layout still degrades acceptably when media queries fail.\n\n### Step 4 - Build the structural scaffold\n\nUse nested presentation tables with explicit spacing controls.\n\n- Use `table`, `tr`, and `td` as layout primitives.\n- Set `role=\"presentation\"` on layout tables.\n- Zero out `cellpadding`, `cellspacing`, and `border`.\n- Keep widths explicit where Outlook needs them.\n- Use predictable spacing with padding on table cells instead of margin-dependent layout.\n\nIf authoring in a readable source format first, plan for a real inlining step before final delivery.\n\n### Step 5 - Implement bulletproof components\n\nBuild every visible component with fallbacks in mind.\n\n- Buttons: make the CTA readable and clickable without relying on background-only styling.\n- Images: always include width, alt text, and an acceptable images-off experience.\n- Typography: use safe font fallbacks and readable default sizes.\n- Dividers, cards, and feature rows: keep them table-based.\n- Background images or rounded CTA treatments: add VML only when the visual requirement justifies the markup weight.\n\nPrefer a plain component that works everywhere over a clever component that fails in one major client.\n\n### Step 6 - Add progressive enhancement carefully\n\nEnhancement is optional. Function is mandatory.\n\n- Add media queries only after the base layout already works.\n- Add dark-mode rules only after the light version is structurally sound.\n- Add hover states or web-font improvements only as bonuses.\n- Use Outlook conditionals for Outlook problems, not for every stylistic preference.\n\nIf a feature cannot degrade cleanly, remove it.\n\n### Step 7 - Design for dark mode and images-off\n\nReview the template in hostile viewing conditions.\n\n- Ensure text still has contrast if colors invert.\n- Avoid relying on pure black and pure white for main surfaces when a softer equivalent is safer.\n- Make logos and icons survive dark backgrounds or inversion.\n- Ensure the CTA remains understandable when images are blocked.\n- Keep meaningful copy out of hero images.\n\nDark mode parity is not required. Legibility and brand survival are required.\n\n### Step 8 - Add accessibility and fallback content\n\nEmail accessibility is part of the implementation, not a cleanup pass.\n\n- Set the document language when you control the outer HTML.\n- Include a descriptive title when relevant.\n- Use meaningful alt text, and empty alt text for decorative images.\n- Keep reading order aligned with the visual hierarchy.\n- Use live text for all essential message content.\n- Include a preheader that complements the subject instead of repeating it.\n- Provide a plain-text version when the send system expects one.\n\n### Step 9 - Trim weight and remove fragile markup\n\nBefore returning the template, reduce unnecessary size and risk.\n\n- Remove unused classes, comments, redundant wrappers, and decorative cruft.\n- Watch total size with Gmail clipping in mind.\n- Do not keep duplicated structures unless a client-specific fallback genuinely requires them.\n- Prefer simple nested tables over sprawling compatibility hacks copied without a reason.\n\n### Step 10 - Test against the client matrix\n\nDo not declare the template ready without a test plan.\n\nAt minimum, verify:\n\n- the required client matrix\n- mobile rendering\n- dark mode where relevant\n- images blocked\n- click targets and link destinations\n- footer and unsubscribe or legal content where applicable\n\nIf the user is asking for code only and no preview tooling is available, return the template with explicit testing notes and the highest-risk clients called out.\n\n## Branching Logic\n\n- **Transactional or lifecycle email.** Default to a narrow single-column layout, one main CTA, low markup weight, and maximum resilience.\n- **Marketing or newsletter email.** Allow more modules, but police size aggressively and keep decorative sections subordinate to render safety.\n- **Adapting a web design.** Rebuild the layout in email-safe structures. Do not transliterate div-based browser markup into email and hope.\n- **Existing template fails in Outlook.** Strip the issue back to tables, widths, padding, conditional comments, and VML needs before changing visual design.\n- **Existing template fails only in dark mode.** Check inversion behavior, transparent assets, and hardcoded colors before touching layout.\n- **Background image is requested.** Provide an Outlook-safe fallback or explicitly recommend dropping the background image.\n- **Multi-column layout is requested.** Use fluid-hybrid stacking rather than media-query-only stacking when older Gmail behavior matters.\n- **Unknown CSS feature seems useful.** Treat it as unsupported until verified against the target matrix.\n- **The HTML is already too large.** Cut modules, wrappers, comments, and decorative code before adding new fallback layers.\n\n## Output Format\n\nReturn the result in the form that matches the task.\n\nFor `draft` or `adapt`:\n\n1. The email HTML, or the corrected section when only part of the template was requested.\n2. Any required supporting notes, such as where CSS must be inlined or where ESP merge tags belong.\n3. Preheader text and a plain-text fallback when the request implies a send-ready email.\n4. A short compatibility note naming the important fallbacks and the highest-risk clients.\n\nFor `review` or `debug`:\n\n1. The concrete rendering problems found.\n2. The corrected HTML or corrected snippets.\n3. The client-specific reasoning behind the fix.\n4. Remaining risks or tests that still need confirmation.\n\nIf required inputs are missing, stop and ask only for the minimum missing items.\n\n## Quality Checks\n\nThe work is ready only when all of the following are true:\n\n1. The layout is table-based and does not depend on unsupported CSS for structure.\n2. Outlook for Windows gets a functional version of the email.\n3. The main CTA is obvious, tappable, and understandable without images.\n4. The email remains readable on mobile.\n5. Dark mode does not destroy legibility or make brand assets disappear.\n6. Images have appropriate alt handling.\n7. Critical content is real text.\n8. The markup is not bloated enough to make Gmail clipping likely without reason.\n9. The template includes the content users expect in an email, including preheader and footer needs.\n10. The response names any assumptions, unsupported requests, or unverified client behavior.\n\n## Failure Modes To Avoid\n\n- Treating email like normal frontend work.\n- Starting from a browser layout and only later thinking about Outlook.\n- Using flexbox or grid for the structural layout.\n- Returning beautiful code that collapses in one mainstream client.\n- Ignoring dark mode until the end.\n- Hiding important text in images.\n- Shipping markup so large that Gmail clipping becomes likely.\n- Adding compatibility hacks that you cannot explain.\n- Claiming a template is ready without naming the test matrix.\n\n## Default Stance\n\nBe conservative, explicit, and honest about compatibility. The plain version that works in Outlook is better than the ambitious version that breaks there. Build from table structure, inline styles, and clear fallbacks first. Treat modern CSS as a bonus layer, not as the foundation.\n\nAssume the final deliverable is hand-authored HTML unless the user explicitly asks for MJML or another authoring system. Support both transactional and marketing email, but default toward the stricter transactional standard when tradeoffs are unclear.",{"name":5,"description":7,"argument-hint":60},"Goal, email type, copy or draft, brand constraints, ESP\u002Fbuild constraints, and target client matrix","main","6b7900ed9e139a153c804e0b1572fd28e83e7f89","skills\u002Fhtml-email-templates",2,"https:\u002F\u002Fgithub.com\u002Fmaltehedderich\u002Fmaster-class-agents","https:\u002F\u002Fgithub.com\u002Fmaltehedderich","hedderich.pro","2026-10-22 03:34:37",{"source":8,"skillName":5,"commands":70,"prompt":80,"zipAvailable":81},[71,74,77],{"tool":72,"command":73},"npx","npx skills add maltehedderich\u002Fmaster-class-agents --skill html-email-templates",{"tool":75,"command":76},"bunx","bunx skills add maltehedderich\u002Fmaster-class-agents --skill html-email-templates",{"tool":78,"command":79},"pnpm","pnpm dlx skills add maltehedderich\u002Fmaster-class-agents --skill html-email-templates","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmaltehedderich\u002Fmaster-class-agents\u002Fblob\u002Fmain\u002Fskills\u002Fhtml-email-templates\u002FSKILL.md",true,[],[84,117,145,174,211,235],{"skillNo":85,"name":86,"nameZh":6,"description":87,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":88,"categories":89,"keywords":97,"publishedAt":55},"01M6QVH72C38RCJ0VRA23F2AMQ","ui-writing","Draft, edit, review, or systematize product interface copy that helps people understand what is happening and take the right next action. Use when working on end-to-end UI flows, buttons and labels, forms and validation, errors, empty and loading states, permissions, confirmations, destructive actions, success messages, onboarding, voice-and-tone guidance, localization-ready strings, accessibility, or copy experiments and audits.","https:\u002F\u002Fgithub.com\u002Fmaltehedderich\u002Fmaster-class-agents\u002Fblob\u002Fmain\u002Fskills\u002Fui-writing\u002FSKILL.md",[90,93,94],{"categoryNo":91,"categoryName":92,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":30,"categoryName":31,"taxonomyType":32,"taxonomyTypeDesc":33},{"categoryNo":95,"categoryName":96,"taxonomyType":32,"taxonomyTypeDesc":33},"01JBSEEDCAT000000000000036","内容创作者",[98,99,100,53,101,102,103,104,105,106,107,108,109,110,111,112,113,114,115,116],"writing","ui","ui writing","permissions","product","actions","messages","edit","ready","next","end","people","states","loading","flows","interface","errors","strings","labels",{"skillNo":118,"name":119,"nameZh":6,"description":120,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":121,"categories":122,"keywords":126,"publishedAt":55},"01M6QVGPXW0MS1RAX8CFJSNBZ6","travel-planner","Plan, build, or review travel itineraries with judgment about pace, routing, and meaning. Use when designing a trip from a vague brief, sequencing multi-city travel, choosing destinations and bases, balancing budget against experience, deciding what to book now vs leave flexible, selecting accommodations, or critiquing an existing itinerary for pacing, routing, and trip quality.","https:\u002F\u002Fgithub.com\u002Fmaltehedderich\u002Fmaster-class-agents\u002Fblob\u002Fmain\u002Fskills\u002Ftravel-planner\u002FSKILL.md",[123],{"categoryNo":124,"categoryName":125,"taxonomyType":32,"taxonomyTypeDesc":33},"01JBSEEDCAT000000000000040","财务",[127,128,129,53,130,131,132,133,39,134,135,136,137,138,139,140,141,142,143,144],"planner","travel","travel planner","brief","Budget","plan","use","do","itineraries","adapt","judgment","now","sequencing","meaning","for","Existing","vague","dates",{"skillNo":146,"name":147,"nameZh":6,"description":148,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":149,"categories":150,"keywords":157,"publishedAt":55},"01M6QVGFKXMFDD9XTB26YGDP6V","terms-of-service","Draft, review, or debug EU SaaS terms of service and online contract terms. Use when writing subscription terms, acceptable-use clauses, liability caps and exclusions, change-of-terms provisions, termination and data-exit mechanics, B2B vs B2C contract structure, DSA\u002FDORA\u002FAI Act overlays, renewal and cancellation rules, governing law\u002Fforum clauses, and ensuring alignment between ToS, privacy policy, and DPA.","https:\u002F\u002Fgithub.com\u002Fmaltehedderich\u002Fmaster-class-agents\u002Fblob\u002Fmain\u002Fskills\u002Fterms-of-service\u002FSKILL.md",[151,154],{"categoryNo":152,"categoryName":153,"taxonomyType":32,"taxonomyTypeDesc":33},"01JBSEEDCAT000000000000030","开发工程师",{"categoryNo":155,"categoryName":156,"taxonomyType":32,"taxonomyTypeDesc":33},"01JBSEEDCAT000000000000037","律师与法务",[158,159,160,98,53,161,162,102,163,164,39,165,166,167,168,169,170,171,172,173],"terms","service","terms of service","policy","change","data","model","alignment","structure","b2b","mechanics","act","dsa","tos","privacy policy","overlays",{"skillNo":175,"name":176,"nameZh":6,"description":177,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":178,"categories":179,"keywords":192,"publishedAt":55},"01M6QVFYP6D72TE1TNKM0J5MDJ","seo-opportunity-analysis","Analyze a product spec to find SEO content opportunities. Use when interpreting a product or company spec, deriving audience search behavior, mapping topical territory, proposing pillar and cluster strategy, prioritizing topics by demand x winnability x business value, choosing the first SEO piece to publish, analyzing the live SERP with the SEO Opportunity Analyst agent, and saving the report as Markdown in docs\u002F.","https:\u002F\u002Fgithub.com\u002Fmaltehedderich\u002Fmaster-class-agents\u002Fblob\u002Fmain\u002Fskills\u002Fseo-opportunity-analysis\u002FSKILL.md",[180,183,186,189],{"categoryNo":181,"categoryName":182,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000019","营销推广",{"categoryNo":184,"categoryName":185,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":187,"categoryName":188,"taxonomyType":32,"taxonomyTypeDesc":33},"01JBSEEDCAT000000000000031","产品经理",{"categoryNo":190,"categoryName":191,"taxonomyType":32,"taxonomyTypeDesc":33},"01JBSEEDCAT000000000000035","市场营销",[193,194,195,196,102,197,198,199,163,200,201,202,203,204,205,206,207,208,209,210],"seo","analysis","opportunity","seo opportunity analysis","search","publish","analyzing","markdown","analyze","analyst","live","gtm","as","mapping","cluster","path","source","company",{"skillNo":212,"name":213,"nameZh":6,"description":214,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":215,"categories":216,"keywords":220,"publishedAt":55},"01M6QVFQDQ386MZT1R5TMBV2B0","seo-content-production","Create SEO content from an opportunity analysis by orchestrating the SEO Brief Architect, SEO Content Drafter, and SEO Content Editor agents. Use when turning a saved or pasted SEO opportunity analysis and optional topic into a brief, draft, editorial review loop, and final Markdown artifact under docs\u002Fseo\u002F.","https:\u002F\u002Fgithub.com\u002Fmaltehedderich\u002Fmaster-class-agents\u002Fblob\u002Fmain\u002Fskills\u002Fseo-content-production\u002FSKILL.md",[217,218,219],{"categoryNo":181,"categoryName":182,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":190,"categoryName":191,"taxonomyType":32,"taxonomyTypeDesc":33},{"categoryNo":95,"categoryName":96,"taxonomyType":32,"taxonomyTypeDesc":33},[221,222,193,223,224,225,53,130,194,226,133,227,228,195,229,230,231,232,233,234],"content","Production","content production","seo content","seo content production","loop","sme","query","draft","material","links","saved","editorial","author",{"skillNo":236,"name":237,"nameZh":6,"description":238,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":239,"categories":240,"keywords":245,"publishedAt":55},"01M6QVFH2FC9922F078WAQQH1W","privacy-policy","Draft, review, or debug EU privacy policies and GDPR transparency notices for SaaS products. Use when mapping lawful basis by processing purpose, documenting data subject rights, defining retention periods, disclosing international transfers (SCCs\u002FDPF), separating cookie\u002Ftracking disclosures, clarifying controller vs processor role boundaries, listing subprocessors, or governing policy change communication for European products.","https:\u002F\u002Fgithub.com\u002Fmaltehedderich\u002Fmaster-class-agents\u002Fblob\u002Fmain\u002Fskills\u002Fprivacy-policy\u002FSKILL.md",[241,242],{"categoryNo":152,"categoryName":153,"taxonomyType":32,"taxonomyTypeDesc":33},{"categoryNo":243,"categoryName":244,"taxonomyType":32,"taxonomyTypeDesc":33},"01JBSEEDCAT000000000000033","数据分析师",[161,246,172,53,162,247,102,248,163,249,250,251,50,39,252,206,253,254,255,256],"privacy","communication","flow","controller","processor","inventory","transparency","retention","processing","transfers","data flow"]